






































































Announcing Simulation Conference 10 
August 25-28, 1986, Washington, D.C 

Four sessions—attend one or all 

• Military Applications, August 25 

• Simulation and SIMSCRIPT II.5, August 26 & 

• Network Analysis, August 28 

• Factory Planning, August 28 

Tools, techniques, and off-the-shelf-models that save time and money 



This conference brings together developers 
and users of simulation to learn about and 
see demonstrations of recent advances. 

Simulation has proven to be an effective 
technique for analysis of problems of mili¬ 
tary planning, factory planning, computer 
and communication network planning, logis¬ 
tics planning and other complex problems. 

This conference is divided into four ses¬ 
sions. You may register for one or more. 
Military Applications, August 25 

• SDI and Simulation 
W. Leon Goodson 

• SDI-Battle Management, 

C3I and Simulation 

Lt. Colonel David Audley 

• TAC THUNDER - 

A Commander’s Perspective 
Lt. Colonel Gary E. Engel 

• Artificial Intelligence 

and Simulation-A Tutorial 
David K. Andes 

• Might’s Linear Program 
Lt. Colonel Robert Might 

• Simulation Testing of Ada 
Embedded Software 

Daniel W. Merdes & Claus P. Janota 

• JESS-The Joint Exercise Support 
System 

Henry G. Kleine 

• JTLS-The Joint Theater Level 
Simulation 

Ronald J. Roland 

• DEWCOM IV and Developmental 
Testing 

George Morales 

• Electronic Warfare- 
DEWCOM IV and COMMANDER 
Dennie Dutschke 

• The Airlift Modules 
of TAC THUNDER 
Zaven C. der Boghossian 

• Developing Simulations- 
A Tutorial for Managers 
Otis F. Bryan, Jr. 

• A Hybrid Approach to Weapon 
Allocations 

David E. Miller 

• Como-A Conversion to SIMSCRIPT II.5 
Charles Howard 

• Logistics Composite Model 
Lieutenant David Davis 


Simulation and SIMSCRIPT II.5 
August 26 and 27 

• Statistical Pitfalls in Simulation 
Modelling 

Averill Law 

• Artificial Intelligence and Simulation 
Using SIMSCRIPT II.5-Tutorial 
David Andes 

• SIMSCRIPT II.5® -A Tutorial 
Edward C. Russell 

• Real-Time Robot Control Systems 
Using SIMSCRIPT II.5 

Peter Bateman 

• Teaching Simulation via 
Team Term Projects 
Timothy C. Diller 

• Building a Knowledge Base 
into a SIMSCRIPT II. 5 Model 
Uri Urmacher 

• Environment Simulation for Testing 
of Ada Embedded Software 

Daniel W. Merdes & Claus P. Janota 

• Real-Time Simulation 
Joel West 

• Conveying Meaningful Information 
Graphically 

Timothy C. Diller 

• Software Design & Documentation 
Language 

Henry Kleine 

• Multi-Player Interactive Simulation 
Scott Shenton 

• Animation and Graphics for 
Simulation Results 
Alasdar Mullarney 

• Status and Plans for SIMSCRIPT II.5 
Product Technical Managers 

Network Analysis, August 28 

• Design Considerations for the Next 
Generation of Networks 

Brian R. Gaines 

• Network Analysis Without 
Programming 

William Garrison 

• Network Research 
Thomas Ward Morgan 

• Protocol Modelling 
Sharon Heatley 

• Canadian Patrol Frigate 
Systems Simulation 
John Roscigno 


Factory Planning, August 28 

• Simulation of Manufacturing Systems 
Averill Law 

• Factory Planning 

Without Programming-A Tutorial 
Bruce Kleine 

• Models, Myths, and 
Mysteries in Manufacturing 
Jack Grant 

• Testing Manufacturing Concepts 
with Simulation 

Gerald Hein 

• How to Choose Manufacturing 
Simulation Software 

Ken Tumay 


Register Now— 

Space is Limited 

This important conference is limited to 300 
participants, and Wash., D.C. hotel accom¬ 
modations are scarce in August. 

I am interested in attending the following 

□ Military Analysis, Aug. 25, $75.00 

□ Simulation & SIMSCRIPT II.5, 

Aug. 26-27, $100.00 

□ Network Analysis, Aug. 28, $50.00 

□ Factory Analysis, Aug. 28, $50.00 

□ Enclosed is a check for $_ 

□ Bill my organization. 

□ Sign me up while I seek approval. 

Name _Phone 


Organization 

Address 


City_State_Zip 

| Return to Cathy Brown: IEEE comp i 

CAC1 

| 3344 North Torrey Pines Court 
[ La Jolla, California 92037 
or call (619) 457-9681 

I_I 

SIMSCRIPT II.5 is a registered trademark and service mark 
of CACI, INC.-FEDERAL 
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FEATURE ARTICLES 



12 Guest Editor's Introduction 

Se June Hong 

The main difference between expert systems and conventional programs is in the degree of separation be¬ 
tween declarative knowledge and the run-time procedural component. 

17 Applications of Al in Engineering 

William S. Faught 

The recent availability of sophisticated Al programming environments is enabling even non-AI scientists to 
rapidly develop Al applications for engineering. 

32 A Rule-Based System to Schedule Production 

Giorgio Bruno, Antonio Elia, and Pietro Laface 

The production scheduler uses a rule'-based approach to handle the operational complexity found in 
flexible manufacturing systems. 

42 A Capacity Planning Expert System for IBM System/38 

Gary Stroebel, Randy D. Baxter, and Michael J. Denney 
In the design and implementation of a capacity planning expert system, primary focus is put on the 
expertise necessary to use a performance model. 

53 Toast: The Power System Operator's Assistant 

Sarosh N. Talukdar, Eteri Cardozo, and Luiz V. Leao 

Toast, a flexible expert system for simulating events in power networks and diagnosing problems, could 
evolve into an intelligent on-line assistant. 

68 The FIS Electronics Troubleshooting System 

Frank Pi pi tone 

FIS uses a causal model to update its beliefs about faults after making tests. It then suggests the next 
best test to apply. 

78 Synapse: An Expert System for VLSI Design 

P. A. Subrahmanyam 

Synapse provides a common basis for different levels of abstraction in VLSI chip design, avoiding the 
usual problem of disjointed concepts at each level. 

92 Knowledge and Control for a Mechanical Design Expert System 

David C. Brown and S. Chandrasekaran 

An expert system using a hierarchical approach following the same procedures humans do shows that 
computers can do routine design work. 

102 PRIDE: An Expert System for the Design of Paper Handling Systems 

Sanjay Mittal, Clive L. Dym, and Mahesh Morjaria 

The PRIDE system uses a large knowledge base that explicitly describes the different elements of design 
knowledge. A prototype version has been successfully tested on real design problems. 

115 Expert Systems in the SDI Environment 

Yi-Tzuu Chien and Jay Liebowitz 

Much research is needed to advance expert systems technology for application to the SDI environment, 
but its potential for helping to fulfill the SDI is great. 
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Parallel Programming 
Languages. See p. 144. 
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Open new doors at Boeing 

Some of the most respected scientific minds in the country are open¬ 
ing new doors to significant advancements in electronics. 

If you’re qualified, you could join them at the new Boeing Electronics 
High Technology Center in Bellevue, Washington. Just minutes from the 
University of Washington and Seattle. In an attractive, creative environ¬ 
ment for advanced research, away from distractions. 

The Center is equipped with state of the art laboratories where you 
can develop, test and perfect your ideas. 

The positions are open to candidates with advanced degrees (MS or 
Ph.D) in Electronic Engineering, Physics, Physical Chemistry, Materials 
Science, Computer Science or Applied Mathematics. 

If you believe as we do, that the most exciting era in Electronics, 
Electronics/Photonics has just begun, send your rdsumd, with present 
and expected salary, to The Boeing Company, P.O. Box 3707-DBE, 
Seattle, WA 98124. Who knows. You may be the next person to 
cross the threshold to an electronics/photonics 
breakthrough. 


Boeing needs world- 
class engineers and 
scientists for these 
specialties 
Photonics 
Fiber optics sensors 
Wideband data devices and 
components 
Infrared and visible 
spectrum sensors 
Optical communications 
Optical information 
processing 

Radio 
Frequency 
Monolithic microwave 
integrated circuits 
Millimeter wave integrated 
circuit technology 
Advanced devices and 
circuit components 
Secure, reliable trans¬ 
mitters and receivers 

Microelectronics 
Radiation hardened circuits 
and devices 

Advanced group III-V circuit 
technology 

Advanced microelectronics 
packaging and interconnects 
Advanced integrated 
circuits 

Information 
Processing 
Ultrareliable computer 
architectures 
High performance com¬ 
puter architectures 
Signal and image 
processing 
Symbolic processing 
Machine vision 
Advanced display 
concepts 
Materials 
Processing 
Crystal growth 
(III-V, II-VI) 

Bulk and thin film device 
fabrication 
Materials and device 
characterization 

Independent 

Research 

Advanced electro-optic 
materials 
3D structures 
Innovative concepts 
















IEEE COMPUTER SOCIETY 
EXECUTIVE COMMITTEE 


President: Roy L. Russo* 

IBM T. J. Watson Research Center 
Route 134 
PO Box 218 

Yorktown Heights, NY 10598 
(914) 945-3085 
Vice Presidents 

Publications (1st VP): J. T. Cain* 
Technical Activities (2nd VP): John D. Musa* 
Conferences and Tutorials: James H. Aylor 
Educational Activities: Glen G. Langdon, Jr. 
Membership and Information: Ming T. Liu 
Area Activities: H. Troy Nagle 
Standards: Helen M. Wood 


Treasurer: Joseph E. Urban 
Secretary: Fletcher J. Buckley 
Junior Past President: Martha Sloan* 

IEEE Division Directors: Martha Sloan, Ronald G. Hoelzeman 
Executive Director: T. Michael Elliott* 

*Ex officio member of Board of Governors 


BOARD OF GOVERNORS 

TERM ENDING 1986 TERM ENDING 1987 


Dennis R. Allison 
Kenneth R. Anderson 
P. Bruce Berra 
Fletcher J. Buckley 
Richard C. Jaeger 
Ming T. Liu 
Michael C. Mulder 
Hillel Ofek 
Edward W. Thomas 
Joseph E. Urban 
Oscar N. Garcia* 


Barry W. Boehm 
Paul L. Borrill 
Glen G. Langdon, Jr. 
Duncan H. Lawrie 
Susan L. Rosenbaum 
Bruce Shriver 
Harold S. Stone 
Wing N. Toy 
Helen M. Wood 
Akihiko Yamada 


PUBLICATIONS 
Dharma P. Agrawal 
Vishwani D. Agrawal 
Dennis R. Allison 
Bill D. Carroll 
Michael Evangelist 
James J. Farrell III 
Tse-yun Feng 
Lansing Hatfield 
Ronald G. Hoelzeman 
Sam Horvitz 

J. T. Cain, Vice President 


BOARD 

Richard C. Jaeger 
Willis K. King 
Duncan H. Lawrie 
Jack Lipovski 
Ming T. Liu 
Michael C. Mulder 
Theo Pavlidis 
David Pessel 
C. V. Ramamoorthy 
Bruce D. Shriver 
Steve Tanimoto 
for Publications 


SENIOR STAFF 

Executive Director: T. Michael Elliott 
IEEE Computer Society 
1730 Massachusetts Ave., NW 
Washington, DC 20036-1903 
(202) 371-0101 

Editor and Publisher: True Seaborn 
Director, Computer Society Press: Chip G. Stockton 
Director, Conferences: William R. Habingreither 
Director, Tutorials: Martez A. Camillieri 
Director, Finance: Mary Ellen Curto 


NEXT BOARD OF GOVERNORS MEETING: 
Hotel Anatole 
Dallas, Texas 

November 7, 1986, 8:30 a.m.-5 p.m. 
THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS, INC. 


President: Bruno O. Weinschel 
President-Elect: Henry L. Bachman 
Executive Vice President: Emerson W. Pugh 
Executive Director: Eric Herz 


Let Us Place You 

IN A 

BETTER JOB NOW 


Put our more than 20 years of experience placing technical pro¬ 
fessionals to work for you. Client companies pay all fees. You 
get our expert advice and counsel FREE. Nationwide oppor¬ 
tunities include technical/management consulting, project/ 
program management, R&D, design, test, systems analysis, 
and V&V in Communications, Defense, Intelligence, Compu¬ 
ter, and Aerospace Systems. 

We are seeking individuals with experience and interest in one 
or more of the following areas of Artificial Intelligence: 

• Expert System Development 

• Knowledge Acquisition and Representation 

• Symbolic Reasoning and Inference 

• Cognitive Modeling 

• Image Processing 

• Verification and Validation 

• Intelligent User Interfaces 

• Natural Language Understanding 

• Software Quality Assurance 

• Software Configuration Management 

• Database Design and Development 

• LISP Programming and Development 

• Signal Processing and Analysis 

• Local Area Networks 
Salaries range from 
$30,000-575,000 plus. 

U.S. citizenship 
required. EB1 SB1 
desirable. Let us place 

rewardingjob . . . now. 

Send your resume in 
confidence to: 

Dept. AA-1C 


WALLACH 

associates, inc. 


Washington Science Center 

6101 Executive Boulevard, Box 6016 

Rockville, Maryland 20850-0616 
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IMS SYSTEMS 
PROGRAMMERS 

Lockheed Missiles & Space Company is seeking 
intermediate and senior level programmers in 
support of IBM’s IMS. 

The selected candidates will hold a BS degree 
in Computer Science, Mathematics, or a related 
field. In addition, you should have a minimum of 
four years IMS Internals with IBM Assembler experi¬ 
ence. OS/MVS Internals experience is desired. 

In this position, your responsibilities will include 
system software development, configuration and 
tuning of IMS systems, and analysis of IMS system 
software failures. 

For immediate consideration, forward your re¬ 
sume to Professional Staffing, Dept. 653EY21, 
Lockheed Missiles & Space Company, RO. Box 
3504, Sunnyvale, CA 94088-3504. We are an 
equal opportunity, affirmative action employer. 

U.S. citizenship is required. 


Lockheed 

Missiles & Space Company 

Giving shape to imagination. 






















At GTE Government Systems, 
Our People Can Afford to be 

Entrepreneurs. 


GTE Government Systems takes you 
beyond the entrepreneurial spirit. We 
back up your initiative and enthusiasm 
with the resources of one of America’s 
largest corporations. Consequently our 
people not only feel free to strive for 
innovative solutions, they also have the 
opportunity to see their ideas at work in 
the real world. 

Put your talents to work at any one of 
the many diverse GTE Government 
Systems areas of specialization. Accept 
the challenges presented by artificial 
intelligence, signal processing, vpice 
technology, lasers, and VLSI. Work on 
key defense programs employing Ada 
and other new languages. Participate in 
design and engineering projects which 
cross the borders of the impossible. 
Innovation, initiative, and independence 
are rewarded with full GTE support. 
Reach your potential working with the 
best equipment, the latest methodolo¬ 
gies, and the most talented profession¬ 
als in your field. We provide the tools, 
the room, and the environment... the 
rest is up to you. 

Some of the current career opportuni¬ 
ties at GTE Government Systems 
include: 

SYSTEMS ENGINEERING 

We are seeking Systems Engineers and 
Technical Managers for: 

• High-speed digital communication 
systems, TDMA/TDM/PCM 

• Spread spectrum communication 
systems 

• Mission planning and control 
systems 

• EW/ESM/ECM systems 

• Al/Expert systems 

• Direction-finding subsystems 

• Receiving and Processing 
subsystems 

• Real-time processing 

• Signal analysis 

• RF tracking systems 

• Over-the-horizon radar 
DIGITAL HARDWARE ENGINEERING 

• VHSIC/VLSI design 

• Digital design 

• Digital signal processing 

• Microprocessor hardware/software 

• Communications signal processing 
RF HARDWARE ENGINEERING 

• State-of-the-art microwave compo¬ 
nent design 

• High power component design for RF 
transmitter 



• Leadership opportunities targeting 
technology developments 

• System applications requiring crea¬ 
tive hardware design contributions 

MECHANICAL ENGINEERING 

• Electro-mechanical packaging and 
miniaturization 

• EMI/TEMPEST packaging 

• Thermal/structure design and 
analysis 

• Project Management 
MIL-SPEC experience required. 
SOFTWARE ENGINEERING 
Opportunities exist for skilled software 
engineers across a full range of 
defense system applications using 
development systems such as DEC/ 
VAX 8600 and MicroVAX II, PDP 11 
series, and the Hewlett-Packard 1000. 
Microprocessor applications are 
directed to Intel 8085/8086, Tl 32020, 
and Motorola 68000 processors. We 
are seeking senior people in the follow¬ 
ing areas: 

• ADA 

Use the DEC/VAX and MicroVAX II 
in our advanced development facility 
to build systems requiring: 

—Real-time analysis and control 


—Advanced MMI: multiple screen, 
color graphics 
—Relational DBMS 
—Networking on ETHERNET/VAX 
clusters 

—Large system development 
(300,000 lines of source code) 
—Microprocessor applications 
(Motorola 68020) 

• FIXED AND AIR-SEA-LAND 
MOBILE SYSTEMS 
Interdisciplinary software/firmware/ 
hardware teams build systems from 
high-level design through final test 
and integration using skills in: 
—Microprocessor applications 
—Real-time analysis and control 
—Test-bed development and 
analysis 

—Mapping and graphics displays 
-Man-machine interfacing 
—Concurrent processing 
—Software architecture design 
—Data base design and applications 
—Al/Expert systems 
THE BAY AREA 

The San Francisco Bay area is one of 
the world’s most attractive locations. 
Here, geographic diversity is enhanced 
by fine climate, cultural richness and an 
abundance of recreational opportuni¬ 
ties. This energetic and dynamic envir¬ 
onment also provides a multitude of 
educational opportunities—many of 
America’s most outstanding universities 
are in close proximity. 

GTE Government Systems offers you a 
competitive compensation package, a 
professional work environment, and 
complete benefits which include 
educational assistance, a stock pur¬ 
chase plan, a tax-deferred savings 
plan, and much more. Please send your 
resume in complete confidence to: 

GTE Government Systems Corporation 

Western Division 

Dept. CC-366 

P.O. Box 7188 

100 Ferguson Drive 

Mountain View, CA 94039 


Government Systems 









LETTERS TO THE EDITOR 


Is the term "Al" just window dressing? 

To the Editor: 

It seems that every complicated computer program is being 
touted as an example of artificial intelligence. I have always 
defined AI as a “learning” program that modifies its own 
structure as it senses its environment. By that standard, few, if 
any, programs in existence are artificially intelligent; they are 
branching programs that are merely complex. I sometimes 
think that AI is a sales campaign for the LISP and Prolog 
languages. 

Software written for avionics systems, even twenty years 
ago, had “expert system” logic such as reasonability tests (for 
example: on sensor values, rates of change and signs), crew in¬ 
terlocks (prohibiting actions that the designer decided should 
not be left to the operator), hysteresis (to prevent chattering 
when operating near a switching point), gain changes, com¬ 
parison logic to detect failures, multisensor Kalman filters to 
calculate instrument errors, etc. These were “expert system” 
decision rules that had their roots in analog control systems. 
Other modern “expert systems” use tables of modes and 
recommended actions, stored as a function of the sensed en¬ 
vironment. These also trace back to early digital and analog 
computers; cheap memory has made automatic mode control 
easier. 

Am I the only one who thinks of AI so restrictively? If not, 
what is AI? 

Myron Kayton 
Consulting Engineer 


Vocationalism and the whole person 

To the Editor: 

The June issue contains a workshop report on liberal arts 
concerns with CSAB accreditation criteria titled “Voca¬ 
tionalism and the Whole Man.” This title not only poorly 
reflects the article’s contents but also gratuitously excludes half 
the undergraduate population. Computer should strive to 
select more accurate titles and to accept its responsibility as the 
flagship of a professional society to advocate equal 
opportunity. 

Martha Sloan 

Michigan Technological University 


Kudos for Ware Myers 

To the Editor: 

Congratulations on Ware Myers’s superb article in the 
March issue of Computer (Vol. 19, No. 3, pp. 89-92). I’m sure 
it helped a lot of people (like me) who only look in on super¬ 
computers every few years. 

Thanks, and keep up the good work. 

Lowell Amdahl 
Computer Sciences Corp. 



TOTALCONTROL 

with LMI FORTH ™ 


For Programming Professionals: 

an expanding family of 
compatible, high-performance, 
Forth-83 Standard compilers 
for microcomputers 


For Development; 

Interactive Forth-83 Interpreter/Compilers 

• 16-bit and 32-bit implementations 

• Full screen editor and assembler 

• Uses standard operating system files 

• 400 page manual written in plain English 

• Options include software floating point, arithmetic 
coprocessor support, symbolic debugger native code 
compilers, and graphics support 

For Applications: Forth-83 Metacompiler 

• Unique table-driven multi-pass Forth compiler 

• Compiles compact ROMable or disk-based applications 

• Excellent error handling 

• Produces headerless code, compiles from intermediate 
states, and performs conditional compilation 

• Cross-compiles to 8080, Z-80, 8086, 68000, 6502, 8051, 
8096, 1802, and 6303 

• No license fee or royalty for compiled applications 

For Speed: CForth Application Compiler 

• Translates “high-level” Forth into in-line, optimized 
machine code 

• Can generate ROMable code 

Support Services for registered users: 

• Technical Assistance Hotline 

• Periodic newsletters and low-cost updates 

• Bulletin Board System 

Call or write for detailed product information 
and prices. Consulting and Educational Services 
available by special arrangement. 


Laboratory Microsystems Incorporated 

Post Office Box 10430, Marina del Rey, CA 90295 
Phone credit card orders to: (213) 306-7412 
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Trying to build an expert system without the 
right tool can really throw a wrench into your system. 

What you need is a tool that provides real 
reasoning power. 

What you need is ART.™ 

ART: The Automated Reasoning Tool. 

ART is powerful enough to develop a highly 
scalable expert system comprised of thousands of 
rules. 

We’re not talking about a boardroom demo. 

We’re talking about a commercially viable 
system you can use in the real world. 


The crucial ingredient is Automated Reason¬ 
ing. It allows computers to formulate conclusions, 
make recommendations, reach decisions auto¬ 
matically. 

It combines the best AI techniques developed 
to date in one. 

Here, take a look: 

• Pattern Matching • Forward Chaining • Backward 
Chaining • Opportunistic Rule Application • Sub- 
goaling • Hypothetical Scenario Generation 

• Comparative Evaluation • Time-Based Reason¬ 
ing • Planning • Simulation • Algorithms • Con¬ 
sistency Maintenance • Meta Knowledge 


BUILDING AN EXPERT SYSTEM IS EASIER 
IE YOU HAVE THE RIGHT TOOLS. 








Ou r expert systems are deep in thought. 

ART has so much reasoning power because 
it not only gives you all the features you need, it 
offers you deep integration of those features. And 
the speed to use them effectively. 

Your expert system can use frames, rules, goals, 
or any type of knowledge. As well as all of ART s 
inferencing techniques. Entirely at the discretion of 
the system. 

Right now, over seventy leading commercial, 
financial, manufacturing, and aerospace 
firms are using ART. 


If you want an AI tool strong enough for busi¬ 
ness, write for our brochure, or call Don Gammon, 
VP of Sales, at 213/417-7997. 

He’ll tell you exactly what makes ART so smart. 

Infer e n c e 


Inference Corporation, 5300 W. Century Blvd., Los Angeles, CA 90045 
Inference Canada Inc.. 5915 Airport Road, Suite 200, Mississauga, 
Ontario L4V 1T1. Contact Don Pepper at 416/671-8405. 

Ferranti Computer Systems Limited, Ty Coch Way, Cwmbran, 

Gwent NP44 7XX, Contact Barrie Avis at (06333) 71111. 

Nichimen Corporation, 11-1, Nihonbashi 3-Chome, Chuo-ku, 

Tokyo 103 Japan. Contact K. Kobayashi at (03)277-5017 
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Explore the Knowledge-based Society 
During the Professional Conference 


Really nine special conferences in one. Just to highlight one of the nine tracks covered at FJCC ’86— 


• Education 




---|j 

FJCC ’86 Presents Algorithms 


• Software Systems 

• Artificial Intelligence 

• Supercomputing 
f Algorithms 

• Modeling/Measurement 

• Computer Design 


LANs are Here—But what technology should you use for your local- 
area net? 

Mike Willett’s track on token-ring networks introduces the technical 
detail on the latest LAN offering. You'll hear about about the IEEE 
802.5 Standard and learn how to use newly developed interface chips 
and fiber optics. Sessions on applications of LANs and the impact 
of networks on information management will help you develop a broad 
understanding of the potential and realities of networks. 

FJCC ’86 will show you how to tap the power of LANs and where 
they will move in the next decade. 


• International Developments 

• Operating Systems/Data Bases/LAN’S 



Do you Recognize the Famous Dates? 


You can hear how it is done and then see it in action at the FJCC ’86. 
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Technical Forum Presentations 

“This is an exciting period in the 
evolution of computer architectures. 
Symbolics, as the leader in symbolic 
processing architectures, wouldn’t miss 
being at FJCC ’86. Our Technical Forum 
presentation at FJCC ’86 will give us a 
unique chance to reach key decision 
makers. This is one show we really have 
to be a part of.” 

Joseph Morin 
Director, 

Federal Systems Group 
Symbolics, Inc. 





















For further conference information, 
return the coupon or contact: 

• Program 

Dr. Harold S. Stone, 

IBM TJ. Watson Research Center 
P.O.Box 218 

Yorktown Heights, NY 10598 


> Professional Development 
Toni Shetler 

TRW Systems Division Wl/4454 
7600 Colshire Drive 
McLean, VA 22102 


Return to: Dr. S. Winkler, FJCC ’86, 1730 Massachusetts 

Ave., N.W., Washington, D.C. 20036-1903 1 

□ YES. I’d like to attend FJCC ’86 and be where the action ^ 
is on November 2-6,1986 in Dallas. I 


_ Telephone _ 


City/State/Country _ 


/ Dr. Stanley Winkler 


Dr. Stanley Winkler 
Conference Chairman 


JOIN US AT FJCC ’86 

INFOMART— Dallas, Texas 

The Fall Joint Computer Conference ’86 
will be the forum for ACM’s and IEEE 
Computer Society’s Annual Conferences in 1986. 

“Successful competition requires 
information and the knowledge to apply 
that information efficiently. FJCC ’86 was 
designed to help provide that information and 
that knowledge. FJCC ’86 is not just ‘another 
conference’ but NINE conferences being held under 
one roof. An important question to ask is, ‘Why attend 
a conference?’ I can think of two major reasons: (1) 
benefits to your company; and (2) benefits to you 
personally. 

Companies will benefit by an early awareness of new 
technologies; avoidance of technological surprise; and 
increased productivity gained by seeing how others have 
solved problems. How can you personally benefit? You 
can personally benefit by interaction with your peers; by 
an improved understanding of the new technologies; and 
by a superior educational experience. Our goal for FJCC 
’86 is to help you to do your job better by coming to 
INFOMART in Dallas in November, 1986.” 


















EXPERT SYSTEMS 


Guest Editor's 
Introduction 


Se June Hong 

IBM IJ. Watson Research Center 


The main difference 
between expert 
systems and 
conventional 
programs is in the 
degree of separation 
between declarative 
knowledge and the 
run-time procedural 
component. 


E xpert (or knowledge-based) systems 
represent a relatively new program¬ 
ming approach and methodology, 
one that evolved and is still evolving as an 
important 'Subarea of artificial int elligence 
research. 

The main difference between expert sys¬ 
tems and conventional programs lies not 
in the delivery of expe rtise, for many com"' 
ventional programs can perform ‘ ‘expert ’ ’ 
tasks. Rather, it lies in the way the pro¬ 
grammer makes use of the different degree 
of separation between the dynamics of 
when to do what to perform a task on the 
one hand, and the “static” (that is, non¬ 
procedural) application-domain knowl¬ 
edge on the other hand. 

In early programs, data and code were 
often intermixed. Modern-day programs 
generally have clearer separation between 
data and program constructs. The expert-— 
systems approach permits even greater 
separation by providing nonprocedura l 
constructs on a still higher level. Such 


separation usually allows more flexibility 
in generating and maintaining the pro¬ 
gram, as well as greater ease of under¬ 
standing, at the cost of run-time overhead 
necessitated by the underlying mech¬ 
anisms that support it. This kind of trade¬ 
off is well demonstrated by comparing 
logic simulation programs: compiled 
simulation versus table-driven simulation. 

For many applications, especially those 
we usually think of as belonging to some 
domain of expertise, it is usually impossi¬ 
ble to define the total flow of actions taken 
by a human problem-solver. Expertise is, 
however, often describable in bits and 
pieces, each relating some small situation 
context and the actions appropriate for the 
situation. E xpert systems provid e a 
mechanism (often"referred to~as an~~7h- 
fere nce ewg/wefToTTifeari these~~pi e rps 
3BgSheiLdynamkalbLat - run-time so as to 
successfully complete a task. Conven¬ 
tional programming basically allows two 
simple options: 
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• test and branch, or 

• do the next action in the list. 

While these two are sufficient for any pro¬ 
gramming task, programmers suffer if 
they must write programs at this level 
when the domain involves expertise that is 
not thus resolvable. 

"tion ot l expert systems relies solely on the 

Characteristics of an ^iLl jsituation-action.p aradigm and gives up in 

PXnert ""-Those cases where only deep reasoning can 

^ provide the solution. Providing special- 

An expert not only possesses a store of r “rs, and representations 

defiiiiHonabfor declarative) knowledge of deep-reasom npaabdit.es m 

-seeci^do mains, is an active argaojAI 


Theorem-provi ng techniques can be used 
for reasoning from the domaiiTpliireiples, 
' if no surface hern is lies ait; available. IIuw- 
ever, theorem-provin gTstrrherentlv expen¬ 
sive c omputationally, and the burden is on 
the "programmers to find as many short¬ 
cut rules as possible to minimize “ deep 
reasoning. 


’ Most of the current genera- 


An expert not only 
possesses a store of 
definitional 
knowledge of a 
domain, but also can 
quickly apply the 
knowledge to a given 
task. 


knowledge to a 
emulate thejDroblem-solving skills of an 
expert, it is not sufficient tcfenSode the 
declarative knowledge separate from the 
procedural component of the expertise, 
leaving the latter to proceed in the fixed 
way provided by an inference engine. A 
good example of this is a chess program 
written in a few pages of Prolog, complete 
with a goal to checkmate. W ith only t he 


research. 




-A * 

Ready-made knowledge. Handling the 
Athe forte of 


"slate-Of-llie-art expert systems. The 
situation-action'knuwledft; is imple¬ 
mented as rlpmmri ns nr ti ™ r,c tn bf tgVpn 


on an i f-needed basis within a frame, and, 
most commonly, as explicit rules. The ini- 
tial success of expert systems was largely" 

Prolog, it would take eonsTcTgenerate t he now e ee an m ‘ 
unoves for a winning play—hardly an ex- 
pert player’s behavior. Procedural knowl- 


knowledee and make inferenc es_with it. 

Still, thereis much progress fobe made in 
improving the expressivity of the rule lan- 

the expert-systems contest ad- tnagejnlemn ce engines tha t in.olte J.hese hijhdenmndtor i 
at a much higher level (that 


attached to da ta) and explicit control lan¬ 
guages are attempts to harness this third 
kind of knowledge; that is, the knowledge 
of when to invoke what at various levels of' N 
detail. Much of thi s procedural kn owledge \ 
(or meta-knowledge), which produces 
focused progress in task performance, I 
may be common to all problem-solving ac¬ 
tivities, while some must be domain spe¬ 
cific. Either way, the means of capturing it 
represents perhaps the weakest part of ex¬ 
pert systems today. Consequently, this is 
an active AI research area. The problem is 
accentuated in engineering applications 
that have many alternative methods and 
high demand for procedural efficiency. 


dresses issues <u a mum mgiiv-i u.™ v-*»«** ---——-—— ;—rr., j— 

of determining the relevancy of actions data 

and subgoals) than the notion of instruc¬ 
tion flow found in conventional programs. 

Three things are essential to being an ex¬ 
pert. First, an expert has know ledge of th e 
concepts relevant to the .domain, its i 


quencing lsTJasIcally goal driven or data 
driven. Kuies usually describe appropriate 

actions in a given situation, but whether 
doing the consequent action now is rele¬ 
vant to the task at hand is often not 
known. Most of the current-generation in¬ 
ference engines, both goal driven and data 
driven, provide depth-first invocation of 
rules, with some limited variations. 

Meta-knowledge. The third kind of 
knowledge is perhaps the hardest to elicit 
from an expert—even when the program¬ 
mer is the expert. Imagine rules as seg¬ 
ments of a flowchart that is cut up into 
pairs consisting of a “test” diamond 
followed by a “procedure” box. Without 
knowing which segment should follow 
, / ' 8< ~. another segment, it would take an enor- 
/ y.wv»~^ mous amount of trial and error for some- 
^ W one to perform the program tasks man- 

Declarative knowledge. There is a ually—if they could be performed at all. 

reasonably - uieM - arra5r-of schemes to Exaggerated though the analogy may be, 

represent this first kind of knowledge, essentially this difficulty is reflected in the 

although most of them can describe only inference mechanisms that are in use 

simple relationships among concepts, today. Meta-rule §jt he use of tags or flags 


onomy, and interrelationships among 
them; if necessary, the expert can solve 
novel problems by reasoning from the do¬ 
main principles. Second, an expert has a 

ans wenTor^ partial* 1 answe rs’ that^ Shortcut 
t heprobleimsglvirigproceis . Third, an ex¬ 
pert has the^hiliI^Je--ceci2gni^^ 
tunities f or using such shortcuts, and ii> 
voices the right ^"situation-action pair” so 
thaffoettsed progress is made toward com¬ 
pleting the given task. 


"The fieldtoday 

Expert systems expand the use of com¬ 
puter s to many application s lor wnich they 
weren’t being used at all or were being 
usedunsuccessfully within conventional 
progr amming''practices . Many successful 




The state of the 


expert-systems applications are beginning 
to appear in medicine, business, finance , 
and engineering. Also, many t ools for 
' Building expert systems, in the form of 
"shells and programming environm ents, are 
beginning to be commercially available. 1 

There have been high expectations and a 
corresponding flurry of activities in this 
area. This brought on some myths and in¬ 
flated expectations about the state of the 
art and the limits of expert systems. Ready 
availability of expertise, the need for intel¬ 
ligent programmers, .user-friend ly inter¬ 
faces, the sound practice ul Soli Ware 
engineering principles, and convenient de¬ 
velopment environments are no less im¬ 
portant to expert-systems applications 
than to traditional programs. Automatic 
acquisition and compilation of knowledge 
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Automatic acquisition 
and compilation of 
knowledge is still a 
goal of Al for which 
research is just 
beginning to yield 
some very limited 
results. 


is still a goal of AI for which research is 
just beginning to yield some very limited 
results. Performance and verification con¬ 
cerns are perhaps more serious for expert 
systems than for conventional programs. 
Yet, it is clear that more applications are, 
indeed, enabled by this addition to soft¬ 
ware technology. The articles in this issue 
represent some of these engineering appli¬ 
cations and some efforts at advancing the 
state of the art so that more engineering 
applications will be made possible. 

In this issue 

The purpose of this special issue is not 
to give a survey or a tutorial on expert sys¬ 
tems, but rather to share examples of engi¬ 
neering applications that depict the advan¬ 
tages, the current limitations, and the 
kinds of tasks being addressed. Engineer¬ 
ing applications may not be genetically 
different from the applications of expert 
systems in other areas, but the articles here 
present samples of what is stressed in engi¬ 
neering applications. For an introductory 
reading in expert systems, articles that ap¬ 
peared earlier in Computer 2-4 would 
make a good start. 

The articles selected for this issue were 
chosen for the maturity of the applications 
they describe, their appropriateness (in ad¬ 
dressing some of the technical issues of ex¬ 
pert systems), and because as a group they 
present a balanced variety of applications 
and R&D activities. Many of these articles 
also demonstrate the need to integrate the 
knowledge-based part of the system with 
existing software and databases. 

The first paper, by William Faught, 
discusses four different applications built 
on KEE. (KEE is a multi-paradigm pro¬ 


gramming environment that features 
frame-based knowledge representation. 5 ) 
It emphasizes the importance of clear, visi¬ 
ble models and advocates building a full 
system by starting out with a bag of tools 
or an intelligent workbench. 

The next paper, by Giorgio Bruno, An¬ 
tonio Elia, and Pietro Laface, describes 
production scheduling for flexible 
manufacturing systems, for which there is 
no known algorithmic solution. The 
authors make use of an intelligent, 
discrete-event simulation that is written 
partly in OPS5 rules and partly in Fortran 
code. (OPS5 is a popular data-driven in¬ 
ference engine. 6 ) Although they note the 
flexibility and ability to incrementally de¬ 
velop the system that this approach makes 
possible, they report on the difficulty of 
maintaining' data integrity between the 
two types of programs. 

Gary Stroebel, Randy D. Baxter, and 
Michael J. Denney present a planning, 
design, and evaluation system for config¬ 
uration of the IBM System/38 computer. 
This application makes use of many ex¬ 
isting programs in the course of perform¬ 
ing a variety of tasks in an interactive ses¬ 
sion. Performance modeling is in APL; 
workload analysis, user-interaction han¬ 
dling, and the configuration generator are 
in Pascal. An evaluation function has been 
implemented in three different versions: 
Lisp, OPS5, and ESE. (ESE uses the goal- 
driven inference in a manner similar to its 
use in Emycin, with an additional mech¬ 
anism to specify certain controls. 7 ) The 
global control and communication among 
these different modules is patterned after 
the blackboard model. The authors 
observe that it was convenient to use shells 
but add that they found them to be more 
awkward at times than straight Lisp, a case 
in point revealing the limited expressivity 
of knowledge representation in the current 
state of the art. 

The blackboard architecture is intended 
for capturing and utilizing the control 
knowledge. 8 While this mechanism in its 
full generality allows flexible and explicit 
representation of high-level procedural 
knowledge, the overhead makes it imprac¬ 
tical for performance-oriented applica¬ 
tions. Many systems implement a simple 
form of such a mechanism. 

Sarosh N. Talukdar, Eleri Cardozo, and 
Luiz V. Leao also make use of a simplified 
blackboard model to coordinate several 


different specialist modules in their sys¬ 
tem, Toast. The domain deals with moni¬ 
toring and controlling utility power sys¬ 
tems as an aid to human operators. The 
system has two parts: an off-line consulta¬ 
tion part that has been implemented, and a 
real-time, on-line control part that has yet 
to be implemented. OPS5 has been 
adapted to run concurrently within their 
distributed problem-solving environment, 
called Cops. 

Frank Pipitone reports on an expert 
diagnostic system for electronic circuits. 
The system has information on failure 
probability, a list of tests, and a list of 
costs. The system finds the “best next 
test” to apply, and upon receipt of the out¬ 
come, updates the “current resolution” 
listing. This system is unique in that ex¬ 
plicit probability calculation is directly 
used with inferences made from compo¬ 
nent-wise behavioral rules and a com¬ 
ponent connectivity description. This sys¬ 
tem is written in Franz Lisp. 

P. A. Subrahmanyam’s Synapse system 
will be a large, complex system when com¬ 
pleted. Intended for designing VLSI chips 
from specification to physical layout, the 
system is designed to deal with multilevel, 
multiperspective descriptions of the chip 
design in progress. Maintaining an alge¬ 
braic model of the intended VLSI func¬ 
tion, the system makes a series of refine¬ 
ment transformations on the model by use 
of production rules. This system also in¬ 
terfaces to many existing programs and to 
special-purpose hardware. The theorem¬ 
proving part is written in Pascal, the 
manipulation of algebraic models is done 
by Macsyma, algorithmic CAD work is 
done by a VLSI workstation, and the rule- 
based expertise is implemented with the 
KEE system. 

The next two articles describe mechan¬ 
ical-design systems. David C. Brown and 
B. Chandrasekaran discuss a language 
designed to capture the task-level knowl¬ 
edge used in creating routine designs. 
“Routine design” refers to those design 
problems in which the intended function is 
well understood and the basic configura¬ 
tion of the design is known. (Nevertheless, 
the designer has to make design choices 
based on complex requirements, and then 
refine and specialize the chosen configura¬ 
tion.) This article represents a research ef¬ 
fort to provide knowledge representation 
closely matching a particular kind of ex- 
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pertise, in this case that of routine 
mechanical design. 

Sanjay Mittal, Clive L. Dym, and 
Mahesh Morjaria, on the other hand, at¬ 
tack nonroutine design—for paper-trans¬ 
port systems. Their article identifies, in 
terms of generate-test-analyze-modify 
cycles, necessary concepts for searching 
through a large design space. Their use of 
multiple specialists to handle design 
subgoals is similar to Brown and Chan- 
drasekaran’s. Their system already con¬ 
tains over 1000 objects implemented in 
Loops. (Loops is a multiparadigm pro¬ 
gramming environment that features 
object-oriented style. 9 ) The authors also 
detail the experience in knowledge acquisi¬ 
tion that they gained, which resulted in a 
100-page document of paper-handling sys¬ 
tem expertise. 

The last paper is by Yi-Tzuu Chien and 
Jay Liebowitz, who present a variety of 
defense-oriented application areas, along 
with system-level requirements. The 
authors point out a list of advances yet to 
be made before such expert systems can be 
practically implemented. These require¬ 
ments and areas of necessary further pro¬ 
gress are not unique to defense applica¬ 
tions, nor to engineering applications. □ 
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EXPERT SYSTEMS 


Applications of Al 
in Engineering 



William S. Faught, IntelliCorp 


of sophisticated Al 
programming 
environments is 
enabling even non-AI 
scientists to rapidly 
develop Ai 
applications for 
engineering. 



R ecently a number of research and 
industrial organizations in the US 
have been investigating artificial 
intelligence techniques to address prob¬ 
lems that have been difficult to solve usmjf 


' ^standard rnmpu taiL _techno[ ogv~~Rgcause 
''knowledge-based systems e xplicitly repr e¬ 
sent and reason with knowledge supplied 
v by h uman experts , these systems offer 
1 Significant new capabilities and flexibilit y. 
The incentive tor applying AI to engineer- 
ing stems not only from the growing com¬ 
plexity of modern engineering but from 
the traditional expense, time constraints, 
and limited availability of human exper¬ 
tise. AI appears to offer an opportunity to 
(1) capture and retain pxnertise that has ac¬ 
crued over many years of engineering, (2) 
amplify expertise that is needed to suc¬ 
cessfully deploy new technologies and 
design applications, and (3) offer systems 
that reason intelligently about necessary 
actions to take in real time, thus freeing 
operations personnel. 1 

There are some problems, however, in 
acquiring AI technology. AI applications 


systems typically require a strong base of 
development tools. Only recently have 
commercial tools become available. Also, 
AI expertise is in short supply, compared 
with the number of potential applications. 

The goal of commercia l tool develop- 
ment is to address these problems by lden- 
tifying AI techniques to include in devel¬ 
opment environments and by supporting 
the development of tool enhancements 
that focus on engineering applications. 
The ultimate goal is to reduce potential 
duplication of effort in tool development 
and encourage commonality among engi¬ 
neering applications. 

Part of this effort is the examination 
and classification of,typical enginee ring 
applications in AL This article briefly 


describes several such applications built 
using IntelliCorp’s Knowledge Engineer¬ 
ing Environment, or KEE. These applica¬ 
tions fall into general categories of fault 
diagnosis, simulation, and configuration. 

The first goal of this article is to describe 
applications and thereby present a clear 
picture of the capabilities of the technol- 
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ogy. The second is to describe for the 
system builder a methodology of building 
systems and lessons learned by the devel¬ 
opment teams. 

Benefits of Al 

AI expert-system building tools typi¬ 
cally provide (1) symbolic representation 
in frames and other symbolic structures, 
(2) symbolic reasoning using rules, 
methods, active values to deduce, com¬ 
pute, examine, determine, and (3) 
graphic explanation s using developer- 
oriented graphic aids (for example, 
knowledge-based graphs and rule graphs) 
and end-user-oriented graphic aids to pre¬ 
sent to the developers and users the 
representation and reasoning. 2 They may 
additionally provide specific problem¬ 
solving paradigms built on frames, rule! 
etc., such as structure selection or con¬ 
figuration of choice sets. 

The benefits of these AI techniques can 
be itemized: 

• Explicit representation of symbolic 
structures, behavior, and reasoning, 
so that the structures can be examined 
and reasoned with (as opposed to 
buried in code). 

• Integration of various types of repre¬ 
sentation. 

• Visibility, resulting from the declara¬ 
tive nature of the representation. 

• Reasoning, in radically different 
ways from those attempted by non- 
AI systems. 

• Intelligent interaction, based on the 
representation. 

• Flexibility/adaptability, resulting 
from the explicit declarative nature of 
the representation. 

Traditional software development in¬ 
volves programmers as problem transla¬ 
tors. The problem is translated by the ex¬ 
pert into a problem statement, which is 
then translated by the programmer into 
code. The programmer runs the code, gets 
the output, and then has to interpret the 
output back to the expert, who then inter¬ 
prets that explanation back to the prob¬ 
lem. Most of the benefits of AI described 
above, however, are oriented toward 
bringing the expert closer to the solution. 
Expert and knowledge-based systems at¬ 
tempt to remove the programmer from the 
loop and allow the expert to interact 


directly with the system to explore the reconfigured. The workstation typically 
problem space. provides the r epresentation and gr aphic 

presentation of the domain, including 

Expert systems VS. , models ancTsimtltetifins of the important 

expert workstations pi ^ obj f t s f and «n«pts to. ^deo^ert 

Lr Ofuofc ) workstation typically leads to ie^af ex- 
emadehe / pert s y stems - Each expert system adds 
specialized and heuristic reasoning to this 


A clear distinction should be made be¬ 
tween an expert system and an expert 
workstation. An expert system (knowl¬ 
edge system for nonexperts) solves a prob¬ 
lem in the same manner as an expert be¬ 
cause it embodies the expertise of an 
expert. The user is not an expert and is 
onl y familial will rtlie dunralirrFhe-svs tem 
makes the decisio ns or suggests the deci¬ 
sions aM ~explains~its conclusions. Note 
that manvj ion-Al systems are expert sys- 
tgms; th ftSrHerence is that A for knowl- 
dedge^secTsvstems anemnr. ib jenrese nt 
]flth e expe rtise explicitly (and therefore pro- 
■vidca basis for explanation ; 1, w fiereas non " 
0 AI j vstems~~Tnav-tervr‘‘compiled” or 
| “translated ' the" expert’s "expertise into 
||F grtrgir Variables~and program state . 
Hments^An expert workst ation (knowledge 
system for experts) provides representa¬ 
tion, reasoning, and graphic s to an e xpert, 
who uses the system to solve a pro Diem or 
sets of problems. The user must be an ex¬ 
pert, because the user, not the system, is 
solving the problem; the system performs 
extensive bookkeeping, thus making the 
expert’s job easier (analogous to a spread¬ 
sheet). The workstation may allow the ex¬ 
pert to solve a set of related problems in a 
single domain area. 

A reasonable development approach is 
to begin by building an expert workstation 
for the problem, then add the expert 
system. In this progressive development, 
the workstation provides the representa¬ 
tion, graphics, and some reasoning and 
serves as a testbed for the expert system. 
Also, the workstation is simpler to con¬ 
struct and involves less risk. Finally, the 
workstation provides a benefit while the 
system is being extended for the expert 
system: The target organization receives 
the new technology and becomes accus¬ 
tomed to it sooner than it otherwise might. 

The key concept underlying the pro¬ 
gressive development of expert worksta¬ 
tions and expert systems is the concept of 
modelzbasedreaso ning.T he major goal of 
tne experF-w orfcstation is to develop a 
model of the problem domain, for exam¬ 
ple, a system being diagnosed or simu¬ 
lated, or a structure of components being 


base. Typically, the same set of models 
and graphics can serve multiple expert 
systems for multiple problems in the same 
domain. 

Of the following applications, the first 
two provide examples of expert systems, 
while the remaining two exemplify the ex¬ 
pert workstation model. 

‘wtomatic fault 
diagnosis in space 
^station life supporty 
/stems 

One of the standard applications of ex¬ 
pert systems that most AI research groups 
begin with is diagnosing faults in a system 
and generating recommendations for 
repair. As part of a study to evaluate the 
feasibility of using a software develop¬ 
ment environment to rapidly design, con¬ 
struct, test, and change AI software, 
NASA Johnson Space Center scientists 
implemented a prototype expert system 
for automated fault isolation and correc¬ 
tion of a CO 2 re mo val subsy ste m desti ned 
for the spacestafi onTsee Figure 1~). The ex- 
pert system simulates the behavior of the 
CS-1 device, an electrochemical C0 2 sub¬ 
system for removing C0 2 from cabin air. 
It allows the user to interactively identify a 
fault to cause (by graphically choosing the 
component on the schematic to fail) and 
then diagnoses the fault. 

The system is an expert system in that it 
mimics the diagnostic stategies of the ex¬ 
pert. One set of rules is used to isolate the 
fault to a particular subsystem; another set 
is then used to find the faulty component 
within the subsystem. 

The system is composed of frames 
(units) to represent each of the com¬ 
ponents and classes of components in the 
CS-1 device; graphics objects to represent 
(1) the graphic images of the device com¬ 
ponents, (2) various gauges that instru¬ 
ment the device, and (3) images that con¬ 
trol the execution of the diagnostic system; 
and two sets of rules for diagnosing faults. 
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Each component in the CS-1 device is 
represented by a unit, or frame data struc¬ 
ture, and is connected to other com¬ 
ponents by slots, or attributes, in the 
frames. The frame representation reduced 
the number of rules in the system by 
eliminating the requirement for rules ex¬ 
pressing the relationship between objects. 
The components are graphically repre¬ 
sented using KEE’s Activelmages, dis¬ 
playing a unique bit-map picture and 
allowing the user to mouse each icon to 
select faults or component states. In Fig¬ 
ure 1, the images in the upper right-hand 
and lower left-hand panels are generic Ac¬ 
tivelmages. The upper right-hand gauges 
represent temperature, pressure, and 
voltage values; the lower left-hand images 
indicate values for flags to control the 
diagnostic system. 

The processing strategy (which mimics 
the expert’s strategy) at each rule level is a 
standard backward-chaining process; a 
number of hypotheses are tested in se¬ 
quence. A unique characteristic of the ex¬ 
pert’s strategy was the subdivision of the 
problem into two levels: The expert first 
determined which subsystem the fault oc¬ 


curred in, then identified the faulty com¬ 
ponent within that subsystem. The diag¬ 
nostic expert system decomposed the 
problem according to this strategy: One 
set of rules determined which subsystem 
was faulty according to heuristics that ex¬ 
amined the pattern of voltages on the 
multiple cells removing the C0 2 . The 
second set of rules, within the context of 
the subsystem, determined which compo¬ 
nent was faulty by examining gauge mea¬ 
surements along the flow of gasses in the 
subsystem. These two sets of rules were in¬ 
voked separately, the first set by a top- 
level command to start the diagnosis, the 
second set by the first set’s successful 
conclusion. 

Another unique characteristic of the 
expert’s strategy was that some of the 
diagnostic conditions involve running 
tests on the system. For example, to 
determine if an object is obstructing a 
valve, the procedure is to test the 
pressure, close and open the valve, and 
then test the pressure again for changes. 
This requires nonmonotonic reasoning 
(reasoning that allows facts to change 
rather than only allowing them to be 
added) and rules such as (IF (PRESSURE 


IS LOW) AND (RUN TEST1) AND 
(PRESSURE IS HIGH) THEN...). This 
illustrates the need for expert-system 
building tools to allow for a wide variety 
of experts’ strategies rather than restrict 
developers to a single paradigm. 

When the developers had completed 
their prototype, they pointed out that the 
simulation they used for generating test 
conditions was a simple (IF FAULT 1 
THEN SET PARAM1, PARAM2, ...) 
model. This required improvement for 
two reasons: 

(1) The test conditions (described 
above) included test procedures that acted 
upon the model, requiring the model to 
respond correctly. These responses were 
essentially hard-coded in the above pat¬ 
terns, as opposed to being represented in a 
model of the device. 

(2) The simple patterns are prone to 
error, since they include “compilations” 
of effects across components. A more ac¬ 
curate model based on each component’s 
behavior would have aided the developers’ 
system validation and testing. 3 

The features of the underlying tool pro¬ 
vided significant leverage in developing 
the prototype. Activelmages were used for 
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Figure 2. The Ford Aerospace system diagnoses faults in the satellite’s power system. 


displaying the schematic, gauges, and con¬ 
trol buttons. The rules were divided into 
classes, thus allowing rules to be parti¬ 
tioned according to the task to be per¬ 
formed. Finally, extensive use was made 
of the multiple inheritance links to express 
as much knowledge as possible and reduce 
the number of rules by making each more 
powerful. 

Diagnosing faults in 
satellite subsystems 

A second diagnostic expert-system ap¬ 
plication using an entirely different strat¬ 
egy is under development by Ford Aero¬ 
space & Communications Corp. scientists. 
The data, instead of being discrete faults, 
occur in telemetry streams to be moni¬ 
tored. The application is an expert system 
modeling several experts’ knowledge 
about how to deal with satellite problems 
during a single pass of the satellite over a 
ground tracking station. Figures 2 and 3 
illustrate the graphic interface to the user. 
The left-hand side displays the subsystem 
being diagnosed. The right and bottom 
edges contain controls for running the sys¬ 
tem and implementing the system’s 
recommendation. 


As the satellite passes over the ground 
station, the diagnostic system detects fault 
symptoms, diagnoses the faults, generates 
recommendations for action, presents the 
recommendations, and allows the opera¬ 
tor to implement the action. The system 
will continue to monitor the fault symp¬ 
toms until they no longer appear (indepen¬ 
dent of the operator’s actions). 

The diagnostic strategy used in this ap¬ 
plication is complex. The expert system 
mimics two sets of experts who each ob¬ 
serve and concern themselves with differ¬ 
ent subsystems of the satellite. The first set 
of experts monitors parameters associated 
with the subsystem being observed. If 
fault symptoms occur, the first set of ex¬ 
perts notifies a second set, who diagnose 
and guard the subsystem until fault symp¬ 
toms disappear. The experts can also con¬ 
fer to negotiate solutions and priorities. 

The system is composed of frames 
(units) to represent each of the com¬ 
ponents, subsystems, and classes of com¬ 
ponents and subsystems in the satellite; 
graphics objects to represent (1) the 
graphic images of the satellite subsystems 
and components, (2) text images that 
allow the user to display the various 
subsystems, and (3) images that control 
the execution of the diagnostic system; 
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and sets of rules for detecting fault symp¬ 
toms, diagnosing faults, and negotiating 
priorities. 

Each component and each subsystem in 
the satellite is represented by a unit, or 
frame data structure, and is connected to 
other components by slots, or attributes, 
in the frames. Several graphic representa¬ 
tions of the components (see Figures 2 and 
3) can be controlled by the text images on 
the right-hand side of the display. In the 
lower portion, the diagnostic system dis¬ 
plays advice to the satellite controller, who 
then either takes action using the YES or 
NO text images or requests an explanation 
using the WHY image. 

The processing strategy for the diagnos¬ 
tic system starts with data-directed reason¬ 
ing. Active values (or “demons”) are at¬ 
tached to each potential fault symptom 
parameter to be monitored. The active val¬ 
ue sends a message to a global “monitor” 
unit whenever the value changes. This unit 
performs simple alarm tests (for example, 
threshold crossings) to determine if an 
alarm has occurred. If so, the global alarm 
unit sends messages to the expert monitor 
units. These in turn use forward-chaining 
reasoning on rules to determine if a fault 
symptom has occurred. 
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Figure 3. The diagnostic system monitors specific subsystem components for failures and generates guardians which diagnose 
the faults and recommend corrective action. 


If a fault symptom has occurred, the ex¬ 
pert monitor unit will spawn a “guardian” 
unit to diagnose the problem. These units 
use a standard backward-chaining para¬ 
digm. A guardian unit will stay in existence 
as long as the symptom that triggered it 
still indicates a problem; when the prob¬ 
lem is corrected, the guardian deletes 
itself. 

Note that both monitors and guardians 
are explicitly represented as units in the 
system (as opposed to being hidden in a 
single set of rules). By using a declarative 
representation of processing (using a unit, 
or frame, for a guardian process), several 
benefits accrued: 

• Each instantiation could be visually 
monitored with a unit and Activelmage. 

• Meta rules could be constructed that 
help select, among the potentially multiple 
faults being diagnosed, which should take 
priority. 

• The guardian expert unit is indepen¬ 
dent of the operator’s actions, allowing 
the guardian to generate recommenda¬ 
tions asynchronous to the operator’s ac¬ 
tions directed at correcting other faults. 

The monitors themselves used rules to 
determine whether a fault existed, and the 
guardians used rules to identify the fault. 
Activelmages were used to represent the 


schematic and controls. The entire devel¬ 
opment screen was covered with user 
graphics to prevent the user from access¬ 
ing the development environment. 

Factory cell simulation 
in aerospace 
manufacturing 

Using SIMKIT, a simulation extension 
to the KEE system, the manufacturing 
planning group at Northrop developed a 
simulation of a factory sheet-metal fabri¬ 
cation cell to perform studies on part rout¬ 
ings, capacity evaluation, and scheduling 
decisions. 

Northrop needed to answer several 
questions: 

(1) How can setup times be reduced and 
throughput be increased; especially, what 
is the impact of having a workstation 
choose from the three or four waiting jobs 
to reduce setup as opposed to selecting the 
first one that arrived (FIFO)? 

(2) How can setup time be reduced by 
simply working with a single thickness of 
metal in any one day? 

(3) What is the impact of doing a rush 
job with a different thickness, thus requir¬ 
ing substantial additional setup time? 


(4) What is the actual time spent in pro¬ 
cess for a job, as opposed to the ideal? 

Figure 4 illustrates the graphic display 
for part of the sheet-metal cell. The central 
area is a schematic of the cell floor, with 
baskets of parts moving along the con¬ 
veyors and waiting in queues. The left- 
hand panel displays classes of machines 
that can be selected and added to the cell 
floor. The images at the top represent 
gauges on simulation parameters. 

Factory simulation illustrates a classic 
expert workstation. The expert configures 
the factory by selecting machines, queues, 
conveyors, etc., and connecting them to 
route parts from one machine to another. 
The expert then selects a routing strategy 
(by part plan, by next available machine, 
by part priority), an order schedule (MRP- 
based, JIT demand pull), an operator 
allocation strategy (strict assignment to 
station, JIT-based assignment to next 
available task), and a station-breakdown 
strategy (based on number of items versus 
number of hours, for example). The ex¬ 
pert then sets the parameters (such as ser¬ 
vice time) and runs the simulation to deter¬ 
mine the effects of the choices. 

The simulation represents a worksta¬ 
tion, with the simulation serving as an ex¬ 
tensive bookkeeper of the implications of 
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Figure 4. The Northrop sheet-metal-factory simulation aids planners in determining the effect of part thickness and setup times on 
plant throughput. 


structural and behavioral choices that the 
user makes. To allow structural choices, 
the left-hand panel has images of classes in 
a library of standard and generic com¬ 
ponents, or machines. These can be placed 
in the model and connected as needed. 
Allowing behavioral choices is more dif¬ 
ficult; standard behaviors are provided, 
but specializations typically require pro¬ 
gramming by the user. 

The system is composed of frames 
(units) to represent each of the com¬ 
ponents and classes of components in the 
factory cell; graphics objects to represent 
(1) the graphic images of the cell com¬ 
ponents, (2) the images of the component 
classes and relation classes, and (3) gauges 
to show the results of statistical data col¬ 
lection (not shown in the figure); rules and 
methods for representing the behavior of 
objects; and rules for verifying the struc¬ 
ture of the model. 

Each component in the factory cell is 
represented by a unit, or frame data struc¬ 
ture, and is connected to other com¬ 
ponents by slots, or attributes, in the 
frames. The components are graphically 
represented using KEE’s KEEPictures 
graphics package, displaying a unique bit¬ 
map picture on the canvas, allowing the 
user to zoom and scroll multiple viewports 


to the canvas. The status of each compo¬ 
nent (both machines and parts moving 
through the simulation) can be displayed 
by mousing the component’s image at any 
time during the simulation. 

The processing strategy for the factory 
cell simulation uses a standard discrete- 
event simulation clock and calendar. The 
blending of simulation and object- 
oriented programming has resulted in a 
powerful programming environment. 4 
Object-oriented programming treats each 
object as an independent processor that 
receives messages, acts on them using its 
own database, and sends messages to in¬ 
teract with other objects. A productive use 
of this strategy in simulation is to treat 
each machine in the factory cell as an ob¬ 
ject and the simulator calendar as an ob¬ 
ject that sends messages to each object 
when it is time to perform its next action. 
The machines in turn send messages to the 
calendar to schedule subsequent events 
and to their parts to move to the next 
machine. 

The expert’s strategy for this problem 
was to configure the system as seen in the 
diagram, then provide a part plan for each 
part. The parts were scheduled to arrive in 
the system in a fixed sequence and at fixed 
times. A series of experiments were then 


run to determine throughput, time spent 
in process, machine utilization, etc. Data 
for these answers were collected using a 
specialized set of units and active values; 
an interactive interface was provided to 
allow the expert to quickly change the type 
of data being collected and displayed. 
The user could also select among ran¬ 
dom-number generators for asynchro¬ 
nous events such as machine failures. 

As can be seen, the main advantage of 
an expert workstation is to remove the bar¬ 
rier between the user and the worksta¬ 
tion—specifically to allow the user with¬ 
out programming skills to modify and 
experiment with the model (modifying 
structure, parameters, and the selection of 
strategies) and to provide visibility into 
structure, behavior, and data collected for 
analysis through graphic depictions. 


Fuel shuffling in a 
nuclear power plant 

As part of a joint effort to develop inter- 
mediate-level tools for AI applications in 
the nuclear power industry, engineers at 
the Electric Power Research Institute and 
IntelliCorp developed a prototype expert 
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Figure 5. The EPRI fuel-shuffling workstation allows reactor engineers to plan shuffling strategies in conjunction with mainframe- 
based fuel depletion simulations. 


workstation application for determining 
the correct shuffle pattern for fuel assem¬ 
blies in a nuclear power plant. 

The problem EPRI addressed was to 
reduce the cost and time required to deter¬ 
mine nuclear reactor fuel assembly con¬ 
figurations. Each nuclear reactor is fueled 
with about 150 to 200 assemblies (each 
containing nuclear fuel). After 9 to 12 
months of operation (one cycle), all of the 
assemblies have been depleted (burned up) 
to some degree. Approximately one third 
are usually discarded and replaced by new 
assemblies. The entire set must then be 
rearranged to create a homogeneous, sta¬ 
ble power distribution that achieves maxi¬ 
mum “burn-up” without spikes of power, 
which require the entire plant to be run at a 
reduced power output level. 

The shuffling strategy and the final con¬ 
figuration are always planned prior to the 
reactor shutdown to make the shutdown 
period as short as possible. (Shutdown 
costs about $500,000 per day.) However, 
the following factors interfere with this 
plan: 

(1) Some of the assemblies may be dam¬ 
aged when inspected or during shuffling, 
thus requiring a new shuffling strategy. 

(2) Shuffling expertise is in short sup¬ 
ply, and personnel may not be current in 


shuffling techniques because they perform 
this task only once or twice per year. 

(3) Shuffling can be the last step in a 
between-cycle maintenance sequence and 
hence on the critical path. 

Once a candidate configuration is deter¬ 
mined, it can be evaluated using PDQ7, a 
mainframe-based program that requires 
about 30 minutes to run. PDQ will deplete 
the reactor (simulate its operation to deter¬ 
mine fuel burn-up and change in composi¬ 
tion) on a time-step basis to determine the 
power distributions during the next cycle. 
Currently, experts manually determine 
each candidate configuration, transfer 
their solution to computer files, run the 
PDQ program, translate the outputs to 
their manual drawings, and repeat the 
process. 

Different experts use different strategies 
and evaluation functions for measuring 
progress toward a solution. One expert 
may go through four to six cycles of deter¬ 
mining a configuration and evaluating it 
using PDQ7 (at an hour per setup and 
PDQ run). A nonexpert may go through 
20 cycles with PDQ7 and get a less satisfac¬ 
tory solution. Most plants try for a stable 
fuel configuration in which the shuffling 
pattern remains the same from one cycle to 


the next. Attempts to reduce the cost of 
running PDQ7 by developing simpler 
PDQ algorithms have not been successful. 

Thus, the fuel shuffling application is a 
good candidate for an expert workstation 
to allow an expert to manipulate fuel 
assemblies, or for an expert system to in¬ 
corporate an expert’s strategy. A proto¬ 
type workstation was developed with a 
minimal set of rules incorporating por¬ 
tions of the expert’s strategy (see Figure 5). 
The lower left corner represents approx¬ 
imately 56 assemblies in the southwest 
quadrant of a reactor core. 

The system is composed of frames 
(units) to represent each of the assemblies 
in the quarter core; graphics objects to 
represent (1) the graphic images of the 
assemblies, (2) various gauges that control 
the evaluation functions, and (3) images 
that control the execution of the worksta¬ 
tion functions; and two sets of rules for 
suggesting procedural problem-solving 
steps and specific assembly moves. 

Each fuel assembly in the quarter core is 
represented by a unit, or frame date struc¬ 
ture, and is connected to the core by slots, 
or attributes, in the frames, indicating the 
assemblies’ positions in the core. The com¬ 
ponents are graphically represented using 
KEE’s Activelmages, displaying a simple 
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Sometimes an expert 
or a developer 
cannot provide a 
one-sentence 
description of the 
problem to be solved 
and may have 
several expert 
systems in mind. 

square bit-map picture overlaid with date, 
unique to the assembly. 

Each of the assemblies in the lower left 
corner (see Figure 5) can be manipulated 
by the reactor engineer by mousing and 
selecting a menu item (for example, mov¬ 
ing an assembly, rotating it 180 degrees, 
symmetrically moving the assembly and its 
twin). The control images on the right side 
of the screen enable the user to select dif¬ 
ferent parameters and evaluation func¬ 
tions for heuristically evaluating a given 
configuration, such as determining “hot 
corners” that have too much energy. 
Another menu choice uses a set of rules for 
suggesting a move or a strategy to pursue 
from the current state. 

The expert’s strategy was to subdivide 
the problem into geometrical subprob¬ 
lems: arranging assemblies in the center, 
on the edges, on the octant axis, and final¬ 
ly in the interior. Within each of these sub¬ 
problems, the expert had additional rules 
—avoiding hot corners, for example, or 
establishing a roughly checkerboard pat¬ 
tern of average assembly energy. After ini¬ 
tializing the configuration, the expert 
moves assemblies for each subproblem in 
turn, marking the assemblies that have 
been moved. The expert then analyzes the 
results using the evaluation functions 
(which tend to be expert-specific) and re¬ 
arranges the configuration as required. 

Finally, the configuration is transmitted 
to a mainframe for PDQ calculations, and 
the results are returned for further shuf¬ 
fling. This involved writing some special¬ 
ized software in the AI environment for 
dealing with card image records on the 
mainframe. 

The application takes advantage of unit 
representation of frames, Activelmages 


for the fuel assemblies and control func¬ 
tions, and rules for the heuristics sug¬ 
gesting moves. The development of the 
prototype reinforced the utility of rapid 
prototyping: The developer used several 
documents as specifications for the ap¬ 
plication, spending several weeks con¬ 
structing the prototype. When the user 
(who wrote the documents) first saw the 
system, several changes were required im¬ 
mediately. Only weeks, rather than 
months or years, of effort had been in¬ 
vested before the user could critique the 
system, resulting in a considerable savings 
in software development effort. 


Methodology of 
developing systems 

The previous discussion illustrates 
several issues in the methodology of 
developing knowledge-based systems: 

(1) Representation, then presentation, 
t hen r easoning. When devHoping a 
knowledge-basedlystem, a reasonable ap¬ 
proach is to first decide on the representa¬ 
tion and represent objects in the domain, 
then develop graphic presentations of the 
objects and concepts, then explore the rea¬ 
soning required for the problem. Most of 
the systems above were developed using 
this approach. The NASA CS-1 system 
and the Ford satellite system developed 
the schematic and underlying components 
and subsystems before proceeding to the 
rules and reasoning. The representation 
and graphics provide a testbed for the 
reasoning component and often lead to 
restructuring the problem before reason¬ 
ing is even attempted. 

(2) A lot_q £j representation, a lit tle rea¬ 
soning. Most problems can be alleviated 
'by Travfng more representation than rea¬ 
soning. Declarative representation pro¬ 
vides an opportunity for reasoning about 
the representation, as seen in the Ford 
Aerospace example of representing moni¬ 
tor processes in units. In addition, many 
unit attributes can be directly represented 
in units, as opposed to rules in rule-based 
systems—for example, the connectivity of 
components in the NASA CS-1 example 
and the fuel assembly positions in the 
EPRI example. Finally, a single rule can 
often be written that is applicable to many 
units, using their attributes as data. 


(3) Simulation with diagnosis. In many 
diagnosis projects (for example, the 
NASA project described above), 90 per¬ 
cent of the development time is allocated 
to the diagnostic program and 10 percent 
to the simulator to drive the diagnostic 
component. When the program is com¬ 
plete, most developers wish they had 
divided their time equally, because they 
would have a better testbed and because 
by producing the simulation they gain ex¬ 
perience with the concepts to be modeled. 

(4) Use a “large hammer.” If the scope 
of the problem or the methodology of the 
expert’s strategy indicates complexity, 
forcing the solution into a single paradigm 
(for example, a single set of rules with tags 
to control their execution) is a mistake. 
The problem must be hit with a “large 
hammer”—a combination of techniques 
integrated to produce the expert’s stra¬ 
tegy. Note that the Ford Aerospace engi¬ 
neers developed guardians and monitors 
to reason and arrive at two different deci¬ 
sions, and the NASA engineers used mul¬ 
tiple rule sets. 

(5) Identify separate expert systems. 
Sometimes an expert or a developer can¬ 
not provide a one-sentence description of 
the problem to be solved and may have 
several expert systems in mind, or an ex¬ 
pert workstation for doing exploration. 
These should be identified and clarified. 


T he unifying paradigm in the applica¬ 
tions and issues presented is the con¬ 
cept of model-based reasoning. 
Each of the applications presented con¬ 
tained an internal model of the problem 
domain (CS-1 device, EPRI fuel assem¬ 
blies, for example), to which rule-based or 
object-oriented-based reasoning was ap¬ 
plied. The models contained an explicit 
description of a domain, typically a struc¬ 
tural (as opposed to behavioral) model of 
objects and relationships between objects, 
and a taxonomy of the object classes. The 
development of the models included de¬ 
velopment of graphic presentations of the 
components and their interrelations. 

The associated reasoning components 
(for example, multiple sets of rules in 
NASA CS-1 and the Ford satellite diag¬ 
nosis) were based on unified domain mod¬ 
els, allowing a variety of different types of 
reasoning over a model. Model-based rea¬ 
soning promotes modularity and integra- 
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tion of reasoning, and assists in decom¬ 
posing complex problem statements. 

Finally, the model, constituting the es¬ 
sence of an expert workstation, can be in¬ 
crementally developed simultaneously 
with the expert system. □ 
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EXPERT SYSTEMS 


A Rule-Based System 
to Schedule Production 


Giorgio Bruno, Antonio Elia, and Pietro Laface 
Politecnico di Torino, Italy 


The production 
scheduler uses a 
rule-based approach 
to handle 
the operational 
complexity found in 
flexible manufacturing 
systems. 


F lexible automation can enhance 
productivity dramatically—but it 
does so by increasing the complexity 
of operations and the difficulty of produc¬ 
tion scheduling, which often means that 
human decisions fail quality and timing 
goals. A flexible manufacturing system 
(FMS) can process many types of parts 
produced in lots from the release times of 
raw materials to the due dates of com¬ 
pleted parts. 

An FMS requires production schedul¬ 
ing that can handle the changes flexibility 
demands. Production scheduling—deter¬ 
mining a schedule (a sequence) of part lots 
to be machined in the FMS—must meet 
the due dates of lots while taking into ac¬ 
count several related problems, such as (1) 
minimizing machine idle times, (2) queues 
at machines, and (3) work in progress. 


Antonio Elia now has a fellowship with Digital Equip¬ 
ment Corp., Turin, Italy. 


Thus, the FMS manager must be pro¬ 
vided with adequate software support for 
two tasks: 

•Production scheduling. This schedul¬ 
ing takes a medium term horizon (two 
weeks) and determines the estimated start¬ 
ing times of lots to allocate auxiliary 
resources, such as manpower for arrang¬ 
ing pallets. The scheduling is subject to 
several constraints, such as planned 
maintenance periods of machines and raw 
material availability times. 

• Real-time rescheduling. This activity 
is invoked when the planned schedule 
must be modified because unexpected 
events occur, for example, when a ma¬ 
chine breaks down or raw materials are 
not available when required. 

The rule-based FMS production sched¬ 
uling system described here is based on an 
earlier system developed with a traditional 
programming language (Fortran-77). The 
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original system is now used in a plant that 
produces several different types of air 
compressor components. 

We chose a rule-based approach be¬ 
cause production scheduling is well de¬ 
scribed by a set of event-driven activities 
operating on a global database containing 
the relevant system state variables. Such 
activities cooperate to solve the complex, 
ill-structured problem of FMS scheduling, 
a task that naturally requires a certain 
amount of reasoning capability and expert 
knowledge because no direct algorithmic 
solution is feasible. Bourne and Fox 1 and 
Fox and Smith 2 have reported other ex¬ 
periences in this field. 

Traditional procedural programming 
languages—such as Fortran and Pascal 
—have commonly been used to implement 
these systems. While the efficiency of such 
implementations is largely acknowledged, 
they cannot adequately satisfy many other 
essential requirements (especially trans¬ 
parency, modularity, and flexibility). In 
procedural languages, the knowledge 
representation and use turn out to be 
embedded in the program’s control flow. 
Adding, deleting, or updating the knowl¬ 
edge is time-consuming for even a skilled 
programmer. 

The lot scheduling problem has been ex¬ 
tensively studied in the operations research 
literature, and many results have been ob¬ 
tained with a wide range of constraints and 
performance measures. Unfortunately, 
such results cannot be applied to produc¬ 
tion scheduling in an FMS because the 
throughput of each lot (the number of lot 
parts produced by the plant per time unit) 


depends on the plant loading condition: 
the mix of lots processed at the same time. 
Hence, the time required to process a 
whole lot is not known until the produc¬ 
tion schedule has been completed. 

Building a schedule involves a series of 
decisions about introducing a new lot into 
the FMS’s current mix of lots. Such a deci¬ 
sion is based on estimating the effect that 
introducing such a lot would have on the 
system performance: machine uses, queue 
lengths, and throughputs of the other lots. 

A well-established model for perfor¬ 
mance evaluation is a closed queueing net¬ 
work where a fixed number of customers, 
such as pallets, are routed according to 
their processing requirements. The advan¬ 
tage of a model based on the closed queue¬ 
ing network is that good performance 
measure estimates can be obtained by effi¬ 
cient heuristic algorithms. 3 

The production scheduling system 
described here combines and exploits two 
different techniques: 

• Expert systems techniques for knowl¬ 
edge representation and problem 
solving. 

• Queueing network analysis for fast 
performance evaluation. 

The scheduling problem 

An FMS essentially contains a set of 
machine tools connected by an automated 
palletized transportation system. The 
main advantages of an FMS are the ability 
to work on different part types simultane¬ 


ously and, consequently, to adapt rapidly 
to changes in production mix and volume 
and the ability to ensure a lower but con¬ 
stant production in case of accidental or 
programmed machine stops. 

The components of an FMS are either 
single-purpose machine tools, such as 
lathes, boring machines, and milling 
machines, or multipurpose machine tools, 
such as machining centers. For each 
operation, machines require the proper 
tools to be available. Dedicated fixtures 
accommodate parts on pallets. A com¬ 
puter lets the plant operate automatically 
by assigning operations to machines, 
mounting proper tools on machines, and 
routing pallets. 

Production scheduling must satisfy the 
following constraints: 

•Production constraints. Each lot can¬ 
not be worked on before its release time 
and should not finish after its due date. 
Lots are characterized by a sequence of 
operations, and each operation can be car¬ 
ried out on a given set of equivalent 
machines. 

• Resource constraints. Several lots 
may use the same fixtures, so they cannot 
be produced at the same time. Moreover, 
programmed maintenance periods for 
machines must be taken into account. 

• Capacity constraints. Machine use 
and average queue lengths should not ex¬ 
ceed predefined limits, otherwise an unac¬ 
ceptable congestion will occur in the trans¬ 
portation system. 

Figure 1 shows the FMS described here. 
It contains a turning center (Ml), four 
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Scheduling can be 
conceived of as a 
discrete event 
decision-making 
process. 


machining centers (M2, M3, M4, and M5) 
equipped with autonomous tool storage, a 
washing station (M6), a blowing station 
(M7), a load/unload station (L/U), and a 
closed palletized transportation system. 

Most machines have a one-place input 
buffer to store parts waiting to be ma¬ 
chined and a one-place output buffer to 
store parts for delivery to the trans¬ 
portation system. 

Scheduling guideline. Because of the 
complexity of the scheduling problem, no 
optimal solution is sought. Instead, the 
scheduler follows a simple guideline given 
by the priority of lots. The priority for 
each lot is a measure of its urgency and 
processing effect on the FMS. It is com¬ 
puted as 

remaining machining time / (due_date - 
release_time). 

Therefore, a schedule can be built by ex¬ 
amining lots according to their priorities 
and by introducing them into the system as 
long as their constraints are satisfied. In 
particular, the scheduler enforces resource 
constraints by making sure that suitable 
fixtures and machines are available. It 
then enforces capacity constraints by esti¬ 
mating the FMS performance if the lot 
were introduced. 

This analysis is carried out by a closed 
queueing network algorithm. If either the 
resulting machine use or the resulting 
average queue lengths at workstations ex¬ 
ceed predefined limits, the lot is not in¬ 
troduced, so the scheduler can examine 
another lot, if there is one. 

Production scheduling is an activity that 
takes place over a period of time because 
not all lots can be introduced into the FMS 
at the same time. Thus, the scheduling can 
be conceived as a discrete event decision¬ 


making process since changes in the sys¬ 
tem can occur only at discrete times (or 
events). Events are marked by an occur¬ 
rence time and are given types according to 

• Lot completion. This lot is removed 
from the FMS and new lots may be in¬ 
troduced. 

• Machine state change. When, for ex¬ 
ample, a machine breaks down or is 
undergoing maintenance, it is no longer 
usable. All lots being machined that have 
no alternative operational machine must 
be removed from the FMS. 

• New lot release. From this instant on, 
the lot can be introduced into the FMS. 

The events belonging to the last two 
types are constraints for the scheduler 
(that is, they are exogenous). However, the 
events of the first type depend on the deci¬ 
sions previously taken by the scheduler, so 
they are determined by the scheduler itself. 
In fact, the completion times of the lots be¬ 
ing processed depend on the current mix 
of lots (because it influences their 
throughputs) and on the remaining num¬ 
ber of parts to be worked on. 

Model simulation. It turns out that this 
approach to production scheduling 
perfectly fits the framework of discrete- 
event simulation. In fact, discrete-event 
simulation is characterized by a global 
simulation clock and evolves with asyn¬ 
chronous timing, since, when an event has 
been processed, the next one is considered 
and its occurrence time updates the 
simulation clock. 

In general, the processing of an event 
will generate other events in the future. An 
important feature of a simulation model 
—a feature rarely offered by conventional 
discrete-event simulation languages—is 
tentatively scheduling future events and 
canceling them later if required. This is 
necessary in production scheduling 
because the completion times of the lots 
being processed depend on the current mix 
of lots, so the insertion or the removal of a 
lot or even the change of state of a machine 
will alter the completion times of those 
lots. 


Scheduler architecture 

It is well-known that procedural control 
is perfectly suited to numerical and algo¬ 
rithmic tasks. However, a nonprocedural 


approach is more appropriate for those 
applications in which most of the knowl¬ 
edge can be represented declaratively. 

The FMS scheduling activity can be 
organized so the advantages of the two ap¬ 
proaches are exploited by two cooperating 
modules: the scheduler, which is a knowl¬ 
edge-based module containing a set of 
rules, and the load evaluation module, 
which exploits its algorithmic knowledge 
to provide the scheduler with a set of per¬ 
formance measures to aid decision 
making. 

Activity scanning. We have adopted the 
activity scanning approach to discrete 
event simulation. Such an approach 
focuses on the activities in which the en¬ 
tities of the system are involved. Each ac¬ 
tivity is prefixed by a precondition that 
triggers its execution. By checking the 
preconditions of all activities, the control 
of the simulation determines when the 
next event occurs and advances the simula¬ 
tion clock accordingly. Then all the ac¬ 
tivities are scanned to establish which can 
be executed. 

This approach could be inefficient 
because of the need to scan each activity at 
each time update. However, it is par¬ 
ticularly suited for situations where the 
duration of some activities is not 
foreseeable because they depend on the 
system’s global state. Indeed, this is true 
for production scheduling. Fishman 4 
presents a more general discussion of the 
main approaches to discrete event simula¬ 
tion. 

The scheduler contains the following 
tasks: 

• Generation of new events. All the ac¬ 
tivities are scanned and the events cor¬ 
responding to the instants at which each 
activity can start are generated. 

• Time update. The simulation clock is 
updated to the earliest occurrence time of 
the events generated in the first phase. All 
the events having an occurrence time 
greater than the selected one are canceled. 

• Activity processing. The activities for 
which an event exists are executed. A par¬ 
tial order can be forced on their execution 
according to the logic of the scheduler. For 
instance, the events related to the state 
change of some machine are served before 
trying to introduce new lots into the FMS. 

Such tasks are executed in a cyclic se¬ 
quence until the stopping condition is 
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TASK1. 

GENERATION OF NEW EVENTS 

1 

machine up 

2 

machine_down 

3 

lot_available 

4 

lot_completed 

5 

if there is a lot L in the state processing then 
generate an event lot_completed referring to L 

at the current_time + (L.total_number-L.current_number)/L.throughput; 

TASK 2. 

TIME UPDATE 

1 

discard_events 

2 

update_simulation_time 

TASK 3. 

ACTIVITY PROCESSING 

SUBTASK UPDATING 

1 

lot_completion 

if there is an event e of type lot_completed referring to lot L then 

update its current number of parts, 
modify L.state to finished, remove L from the FMS, 
update the throughputs of the other lots in the FMS, 
release the fixture L.fix, cancel the event e 

2 

lot_suspension 

3 

u pdate_n u mber_of_parts 

4 

lot_availability 

5 

machine_down 

6 

machine_up 

SUBTASK INSERT LOTS 

7 

lot_insertion 

if there is a lot L in the state available 
and the fixture L.fix is free and there is no other lot which 
satisfies the same conditions and has a higher priority and has not 
yet been considered at this time and lot L can be introduced into the 

FMS then 

get the fixture L.fixt, 
modify L.state to processing, 
introduce L into the FMS; 


Figure 2. The production scheduler architecture. 


reached. The stopping condition occurs 
when all the lots have been completed or a 
predefined interval has elapsed. 

Structured implementation. Figure 2 
shows the scheduler framework. The rules 
in the third task are grouped in two sub¬ 
tasks that are activated in sequence. When 
there are no longer applicable rules in a 
subtask, the next subtask is activated. 

The structure of the scheduler lends 
itself to a straightforward implementation 
by using a production system program¬ 
ming language. This programming ap¬ 
proach offers the advantages of modulari¬ 
ty and flexibility because the data, knowl¬ 
edge, and control are separated. In fact, a 
rule of a production system represents an 
independent component of the overall sys¬ 
tem’s behavior and reacts to a specific 
situation. 

This encourages structured devel¬ 
opment by stepwise refinement that in¬ 
crementally adds and verifies new features 
and constraints. Since extensions and up¬ 
dates of the system require relatively little 
effort, this approach is well-suited for 
rapid prototyping. Moreover, this ap¬ 
proach lets heuristic knowledge be in¬ 
troduced in the form of behavioral rules 
that can be suggested by a scheduling ex¬ 
pert. These rules can take into account 
quantitative and qualitative aspects in¬ 
volved in the decision. 

An example of such a rule is the follow¬ 
ing: 

if a lot is available and could be sched¬ 
uled but it is foreseen that an essential 
machine must undergo a maintenance 
period in a short time 

then delay this lot and try to schedule 
another one. 

The load evaluation module basically 
implements a closed queueing network al¬ 
gorithm that deals with capacity con¬ 
straints and optimization issues. Its task is 
quite limited. Well-structured chunks of 
procedural knowledge are available to it. 3 

The algorithm is based on the assump¬ 
tion that the FMS state is completely deter¬ 
mined by the current mix of lots. It im¬ 
plements an efficient heuristic extension to 
the mean-value analysis technique 5 for 
closed queueing networks. It receives as 
input the information about the lots being 
processed and returns as output the values 
of machine use, average queue lengths, 
and lot throughputs. 


Scheduler 

implementation 

The scheduler was written in OPS5, a 
rule-based, domain-independent produc¬ 
tion system language. 6 An OPS5 program 
contains a global database, called working 
memory, and a set of rules operating on it. 

Figure 3 illustrates the data structure for 
production scheduling with a simple and 
informal graphical notation that shows 
the system’s objects and the relationships 
between them. Objects are represented by 
rectangular boxes, while relationships are 
depicted as labeled arcs. 

Objects belong to classes and have at¬ 
tributes. A particular attribute is the name 
of the object. In the figure, each object is 


denoted by the name of its class in upper¬ 
case and by its name in lowercase. An arc 
between two objects indicates that a link 
exists between them. Such a link is carried 
out by storing the name of the object the 
arc is directed to into an attribute of the 
object the arc emanates from. The name 
of this attribute labels the arc. 

As the figure shows, each lot is charac¬ 
terized by several operations that can be 
performed on a set of equivalent ma¬ 
chines. The objects of the class mach^set 
represent such sets. 

We chose this data organization because 
it reflects the entity-relationship ap¬ 
proach, 7 a well-known data management 
method. Furthermore, it fits the structure 
of the OPS5 working memory well. 
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Figure 3. The production scheduler data structure. 


( LOT 

‘ name 

; name of the lot 

‘ state 

; state of the lot (unavailable, available, processing, finished) 

* release_time 

; arrival time of raw materials 

" due_date 

; delivery time of finished parts 

* total_number 

; number of parts to be produced 

■ current_number; 

; current number of parts 

‘ priority 

; dynamic priority of the lot 

• fixt) 

; name of the fixture 

( EVENT 

■ type 

; type of the event 

‘ refers__to 

; name of the object it refers to 

* time) 

; occurrence time of the event 

( CANDIDATE_GOAL 

* lot_name 

; lot whose introduction in the FMS has to be evaluated 

' priority) 

; priority value of the lot 

( EVALUATION_GOAL 

" result 

; result of the evaluation (positive, negative) 

* lot_name) 

; lot whose introduction in the FMS has been evaluated 

( CONTEXT 

* task 

; ' subtask * step) 


Figure 4. Examples of working memory elements. 


A working memory element contains 
tuples of attribute-value pairs. The at¬ 
tribute names are prefixed by “ , while 
their values are constants. Some examples 
of working memory elements are given in 
Figure 4. 

OPS5 interpreter. In OPS5, each rule 
has a lefthand side composed of a set of 
condition elements and a righthand side 
that specifies actions. A condition element 
is a pattern containing both constants and 
variables (denoted by names within angle 
brackets [< and >]). 

The OPS5 interpreter cyclically per¬ 
forms a recognition-action loop, during 
which the condition elements are matched 
to the working memory elements. This 
process binds attribute variables that have 
the same name to working memory ele¬ 
ments that have the same attribute value. 
When all the condition elements in a rule 
are satisfied, the production is instantiated 
and enters the conflict set. 

The OPS5 interpreter selects for exe¬ 
cution one instantiation of this set with a 
user-specifiable strategy. For this sched¬ 
uler implementation, we chose the special- 
case strategy. According to this strategy, if 
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TASK 3. ACTIVITY PROCESSING. SUBTASK INSERT_LOTS 

;RULE 3.7 STEP 1 


:A aoal is generated for each candidate lot 

(p candidate_machinable_ 

—lot 

(context 

task activity_processing 
subtask insert-lots * step 1) 
name <l> ' state available 

priority <p> ' fixt <fix>) 

(lot 

(fixture 

name <fix> * state free) 

(make candidate_goal * lot_name <l> priority <p> )) 

Switching to the next step 


(p candidate machinable. 

_lot—end 

{(context 

task activity—processing 
subtask insert-lots ‘ step 1) <c>} 

(modify <c> 

step 2)) 

;RULE 3.7 STEP 2 


jselects the lot with the highest priority and evaluates the effect 

;of introducing it into the FMS by calling PERFORMANCE—EVALUATION function 

(p evaluate_lot 


{(context 

type activity—processing 
subtask insert—lots * step 2) <c >} 

{(candidate_goal 

priority <p> ‘ lot_name <l> )<goal>} 

(lot 

name<1> ‘ fixt <fix > ) 

(fixture 

name < fix > * state free) 

- (candidate_goal * 

priority { <p1> > <p>}) 

(bind <evaluation> ( PERFORMANCE_EVALUATION <l>)) 

make evaluation_goal 


result <evaluation> * lot_name<l> ) 

(modify <c> 

step 3) (remove <goal > )) 

;RULE 3.7 STEP 3 


;lf the evaluation is positive, the lot is introduced into the FMS 
;by calling the INSERT_LOT function 

(p define_processing 


{(context 

type activity—processing 

subtask insert_lots' step3)<c>} 

name <l> ' fixt <fix> )<lot> } 
name <fix>) <fixture> } 

{(lot 
{(fixture 

{(evaluation—goal 

result positive ' lot_name <l> )<g> } 

(modify <c> 

step 2) 

(modify <fixture> 

' state used) 

(modify <lot> 

' state processing) 

( bind <reslot > (INSERT. 

_LOT <!>))( remove <g >)) 


Figure 5. Examples of 0PS5 rules. 


there are given two instantiations, the one 
with the greatest number of condition 
elements is chosen because it is considered 
more specialized for dealing with the cur¬ 
rent situation. Figure 5 presents some 
OPS5 rules that correspond to the organi¬ 
zation in Figure 2. 

Rules are partitioned into tasks, sub¬ 
tasks, and steps with a working memory 
element, called context, that indicates the 
active task and any active subtask or step. 
Tasks and subtasks correspond to those 
indicated in Figure 2. Steps have been in¬ 
troduced because some of the high-level 
rules shown in Figure 2 cannot be im¬ 
plemented by a simple OPS5 rule but in¬ 
stead require a sequence of OPS5 rules. 

Some rules are devoted to task, subtask, 
or step switching. In fact, for each context 
there is a rule containing only the condi¬ 
tion sensitive to it. This rule deactivates the 
current context and activates a new one by 
changing the attributes of the context ele¬ 
ment. Since the deactivation rule is a 
general case of all the other rules sensitive 
to the same context, it fires only after all 
the other rules in the context have been 
satisfied. 

Separate data structures. The integra¬ 
tion of the rule-based system and the 
closed queueing network algorithm is not 
straightforward because of the deep dif¬ 
ferences between the corresponding pro¬ 
gramming techniques. A major conse¬ 
quence of these differences is that two 
separate—but consistent—data structures 
are maintained. Both modules, in fact, 
must record information about the entire 
state of the system, but the form in which 
the information is organized and its con¬ 
tents are different. 

To maintain the consistency of such 
data structures, the modules must com¬ 
municate. The data structure of the 
scheduler is loaded, in the initialization 
phase, by simple actions that create work¬ 
ing memory elements. Since it is impossi¬ 
ble to address working memory elements 
from a foreign environment, a parallel 
data structure is created for the queueing 
network analysis algorithm to use. 

Thus, communication is achieved by a 
set of production rules in the form of ex¬ 
ternal function calls. The external func¬ 
tions are implemented in Fortran-77 and 
are referred to in uppercase. The exchange 
of information between the modules takes 
place through the following mechanisms: 


• Actions that request some perfor¬ 
mance index to be externally computed. 
For example, the evaluation of the load 
caused by the introduction of a new lot 


into the FMS (PERFORMANCE_EVAL- 
UATION). 

• Actions that announce a change in the 
state of some entity. For example, a lot 
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that must be introduced into the FMS (IN- 
SERT_LOT). 

• Rules that monitor external events 
such as machine failures. These rules use 
the VAX/VMS operating system service 
routines and the related asynchronous 
system trap mechanism to interrupt the 


program when a particular event occurs. 
This proves valuable during real-time 
rescheduling. 

For efficiency, most of OPS5’s power 
relies on its complex and flexible pattern¬ 
matching mechanism. The matching pro¬ 
cess is complicated and could be a major 


source of trouble, but Forgy has devised a 
very efficient implementation 8 based on 
the reasonable assumption that a small 
number of working memory elements 
change at every recognition-action cycle. 
Moreover, the communication between 
the modules, although rather frequent, in- 


Table 1. A schedule of the machine time needed to carry out each operation associated with a particular lot. Each 
machine (Ml, M2, and so on) that falls within the time span of an operation is capable of carrying out that operation. 



Lot 01 
(100 Parts 
Processed) 

Lot 02 
(150 Parts 
Processed) 

Lot 03 
(200 Parts 
Processed) 

Lot 04 
(100 Parts 
Processed) 

Lot 05 
(100 Parts 
Processed) 

Lot 06 
150 Parts 
Processed) 

Lot 07 
(175 Parts 
Processed) 

Lot 08 
(100 Parts 
Processed) 

Lot 09 
(200 Parts 
Processed) 

Lot 10 
(100 Parts 
Processed 

Lot 11 
(100 Parts 
Processed) 

Ml 

M2 

M3 

M4 

M5 

8.64 min. 

19.49 min. 



12.94 min. 

12.14 min. 








11.38 min. 

16.33 min. 

13.25 min. 

18.11 min. 

26.65 min. 

19.54 min. 

16.06 min. 

15.94 min. 




M6 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

4.22 min. 

M7 

4.00 min. 

4.00 min. 

4.00 min. 

3.00 min. 

4.00 min. 

4.00 min. 

4.00 min. 

4.00 min. 

3.00 min. 

4.00 min. 

4.00 min. 


1 


•5 

1 

z 


Time (minutes) 


Figure 6. Production rates achieved by following the schedule described in Table 1. 
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volves the exchange of only a few pieces of 
information. 

We have compared the current OPS5 
system and the original Fortran-77 version 
for a few examples. The results show that 
there is no appreciable increase in the 
response time of current scheduling with 
respect to the old one. This can be justified 
since the procedural approach implies an 
iterative monitoring of all possible 
changes that might affect the system state. 

An example 

Table 1 summarizes the essential param¬ 
eters of the simple scheduling problem 
described here and the methods used to 
solve the problem. For example, three 
operations are associated with LOT03: the 
first one lasts 16.06 minutes and can be 
carried out by machine M4 or machine 
M5, while the other operations are exe¬ 
cuted by machine M6 and machine M7, 
respectively. 

We have made further assumptions for 
the sake of simplicity in the presentation of 
the results: 

• Lots have equal release times and due 
dates. 

• Lots require different fixtures. 

• Only one machine, machine Ml, 
undergoes a maintenance period, 
lasting 500 minutes every 3000 
minutes. Its first maintenance period 
starts 1000 minutes after the lots’ 
release time. 

The number of parts produced for each 
lot at any given time is shown in Figure 6, 
which summarizes the main decisions 
taken by the scheduler. 

When the raw materials are released, the 
scheduler lets only eight of the 11 lots be 
introduced into the FMS because of 
capacity constraints. The order in which 
lots are selected depends on their dynamic 
priority. 

In our example, LOT05, which must 
produce 100 parts (each of them requiring 
a relatively long operation performable 
only by machine Ml), is the most urgent. 
LOT01, LOT04, and LOT08 can be 
delayed without causing any trouble 
because it is easier to respect their due 
dates. 

The unavailability of machine Ml at 
time 1000 for 500 minutes is the next event 


that compels the scheduler to remove 
LOT05 and LOT06 because no alternative 
machine can carry out the job. As a conse¬ 
quence, the production rates for the other 
active lots increase slightly. 

At the end of the maintenance period (at 
time 1500), LOT01 and LOT06 are 
scheduled. LOT05 is not rescheduled 
because LOT01 has gained priority over it 
because of its greater estimated remaining 
machining time for completion and 
because the queueing network analysis 
suggests these three lots would overload 
the system if scheduled at the same time. 

Another available lot, LOT08, can be 
introduced instead, and thus there is an 
update on the production rates of the dif¬ 
ferent lots. 

The completions of LOT02, LOT 10, 
and LOT11 do not generate significant 
changes on the production rates. Instead, 
it is again the unavailability of machine 
Ml (at time 4500) that lets LOT04 be 
scheduled and interrupt LOT01. 

Finally, after the machine Ml is 
repaired, LOT05 and LOT01 can be com¬ 
pleted, while LOT06 must wait again at 
time 8000. 


T he experience gained in restyling the 
production scheduling system for an 
FMS by exploiting nonprocedural 
programming shows that 

• A dramatic increase in flexibility and 
maintainability of the resulting system has 
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EXPERT SYSTEMS 


A Capacity Planning 
Expert System for IBM 
System/38 

Gary J. Stroebel, Randy D. Baxter, and Michael J. Denney 


V. 


In the design and 
implementation of a 
capacity planning 
expert system primary 
focus is put on the 
expertise necessary 
to use a performance 
model. 


System Products Division 


E xpert system technology offers con¬ 
siderable promise for addressing 
many of the problems associated 
with the performance management of 
computer systems. McDermott 1 describes 
an expert system to assist a user perform 
hardware configuration tasks. Griesmer et 
al. 2 discuss an expert system to advise the 
system operator. Kornell, 3 Hellerstein 
and Van Woerkom, 4 and Artis 5 present 
expert systems to analyze and interpret 
performance measurement data. Levine 6 
describes an expert system to advise an 
analyst on several key performance 
management issues. 

This article deals with the application of 
expert systems to the capacity planning 
problem. Capacity planning is the process 
of understanding and predicting the per¬ 
formance of a computer installation in 
order to maintain sufficient processing 
capacity. For a prospective account this 
process begins at proposal time. The pro- 


A version of this article first appeared in the CMG 85 
Conference Proceedings, Dec. 9-13, 1985, Computer 
Measurement Group, Inc., Alexandria, Virg., pp. 
204-212. Used with permission. 


posed configuration must be large enough 
to handle the projected work load and still 
remain cost competitive. For an installed 
system, capacity planning is an ongoing 
process. Over a period of time, installa¬ 
tions grow in their data processing de¬ 
mands. This growth requires periodic 
enhancements to the configuration in 
order to maintain acceptable levels of 
performance. 

The amount of effort, time, and exper¬ 
tise required in the capacity planning pro¬ 
cess varies widely with the particular 
system product and the customer’s en¬ 
vironment. However, every installation re¬ 
quires some degree of capacity planning. 
The technical literature contains many ar¬ 
ticles on the capacity planning process (for 
example, references 7, 8, and 9). Some of 
these present general concepts and tech¬ 
niques applicable to any system. Others 
provide procedures and “rules of thumb” 
specific to a particular system. Most apply 
to existing installations as opposed to pro¬ 
posal situations. 

There are many tools available to assist 
the capacity planner. These include perfor¬ 
mance measurement packages, data re- 
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duction programs, performance predic¬ 
tion models, and configuration guidelines. 
These tools are essential ingredients in the 
capacity planning process. A good deal of 
expertise, however, is often required in 
order to use them effectively. 

Performance measurement tools are 
good (perhaps too good) at producing 
numbers. Only the “skilled” eye can cor¬ 
rectly interpret these numbers and relate 
them to end-user performance. From an 
input configuration and work load, per¬ 
formance prediction models compute 
response time, throughput, utilizations, 
etc. It takes a good understanding of per¬ 
formance analysis concepts and of the par¬ 
ticular system under study to effectively 
use these models. Published guidelines are 
often too general to be directly applied to 
any specific situation. 

Expert system technology offers con¬ 
siderable promise in bridging this gap be¬ 
tween the specialized, technical challenges 
of the capacity planning process and the 
performance needs of customers. The ex¬ 
pert system contains encoded knowledge 
about computer performance analysis and 
capacity planning. This knowledge is re¬ 
quired to properly interpret measurement 
and model results, and to guide the capac¬ 
ity planning process to a goal consistent 
with the customer’s data processing 
requirements. 

Whether one views the various support 
tools (models, measurement tools, data re¬ 
duction packages, etc.) as part of the ex¬ 
pert system, or as outside support to the 
expert system, is not important. For the 
most part, we include these support tools 
as part of the system. The main point is 
that these support tools by themselves 
represent little, if any, “knowledge” 
about the capacity planning process. His¬ 
torically the user has had to provide this 
knowledge. With an expert system, con¬ 
siderably more “intelligent function” is 
provided to the user by the facilities 
themselves. 

The focus of our expert system is on the 
effective use of a performance prediction 
model in the capacity planning process. 
The model is used to estimate the effects of 
work load and/or hardware changes on 
performance. It is also used as a design 
tool to determine hardware configurations 
capable of supporting a work load (either 
real or projected) at a desired performance 
level. 


The “expertise” is introduced in the in¬ 
terpretation of the model results. The 
model is solved for a particular hardware 
configuration and work load. The “per¬ 
formance expert” then analyzes the model 
results in view of user performance objec¬ 
tives, configuration constraints, and var¬ 
ious design guidelines. This analysis and 
interpretation is then used to guide the 
process of designing an appropriate con¬ 
figuration. 

In the second section an overall struc¬ 
ture or paradigm is presented for a capac¬ 
ity planning expert system. This descrip¬ 
tion is quite general and can be applied to 
the development of a capacity planning ex¬ 
pert system for any computer system. In 
the third section, this framework is used to 
develop PEP38 (Performance Expert Pro¬ 
totype for IBM System/38). Finally, some 
of our experiences and directions for 
future work are discussed in the fourth 
section. 

Capacity planning 
expert system structure 

The capacity planning process. There 
are several facets to the capacity planning 
process, each of which must be integrated 
into the expert system. First, the installa¬ 
tion work load must be characterized. For 
an existing account this characterization is 
most often obtained from measurements. 
These measurements are in a form close to 
that required by a performance prediction 
model, for example, CPU time per trans¬ 
action, working set size, and I/O activity. 
For a prospective account, however, ap¬ 
proximate characterizations must be 
determined from a higher level description 
of the customer applications. This descrip¬ 
tion must then be mapped to a level re¬ 
quired by the model. This mapping is dif¬ 
ficult and requires a good deal of skill and 
experience from the capacity planner. 

Specifying credible performance objec¬ 
tives is the second ingredient of the capac¬ 
ity planning process. Objectives for re¬ 
sponse time, interactive throughput, and 
batch processing must be established. 
These, along with guidelines on resource 
utilizations, are used by the experienced 
capacity planner to assess the performance 
of a particular configuration. 

The third facet of the capacity process 
involves configuration parameters and 


The focus of our 
expert system is on 
the effective use of a 
performance 
prediction model in 
the capacity planning 
process. 


constraints. Each CPU is characterized by 
an instruction processing speed, disks are 
specified in terms of their access times and 
capacities, and I/O device specifications 
include rated throughputs. The manufac¬ 
turer often imposes constraints on mar¬ 
ketable configurations; for example, a 
maximum main memory size and disk 
configuration are associated with each 
CPU model. Finally, the capacity planner 
for a particular installation introduces 
additional configuration constraints on 
cost, minimum disk storage, bounds on 
the number of terminals, etc. 

The fourth feature of the capacity plan¬ 
ning process is a performance prediction 
model. Given a hardware configuration 
and work load, this model estimates per¬ 
formance parameters such as response 
time, throughput, and utilizations. Cer¬ 
tainly a good deal of skill is required to 
build such a model, but this particular ex¬ 
pertise is not addressed here. However, 
considerable skill is also required to use the 
model effectively in a capacity planning 
role. This skill is incorporated into our ex¬ 
pert system. 

The remainder of this section describes 
how these facets of the capacity planning 
process can be integrated into a single sys¬ 
tem. The emphasis is on the structure of 
the system and the general functional 
capabilities of its constituent components 
as opposed to implementation detail. 

The blackboard paradigm. In most 
large~e *pe iT sy s tems tnere Is a need t o in¬ 
tegrate a variety of diverse f unctions . 
Some of these functions, such as graphical 

displays and mathematical modeling, are 
performed best using conventional pro¬ 
gramming techniques. Other functions 
such as expert level evaluation may be best 
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represented by a rule-based, declarative 
approach. An architecture that will sup- 

I port these diverse functions is therefore re¬ 
quired. A modification of the blackboard 
paradigm 10 has been used in which each 
of the major functions has been encoded 
in a separate, independent module. 

The idea behind the blackboard ap¬ 
proach is simple. The entire expert system 
consists of a set of independent software 
modules and a ‘‘5l ackb oaf5 H^a^ftared 
Hpta ctnirtnrp tc TwHiclTall of the modul es 
^have acce ss (see Figure 1). Each module 
"has a welTdefined role (specified in terms 
of maintaining various data structures), 
and is required to support an interface 
appropriate to that role. A module has no 
dependency on the internal structure or 
implementation details of the other 
modules. 

blackboard is used as a means of 
co mmunication hetween~ mo rliiles~~Tn 
order to solve problems, modu les place 
their result s on the bla ckbo ard! 
modules res pond to tne changes i 
blackboard/ When a~Tiarticular module Is 
activated, it examines the current contents 
of the blackboard and either adds new 
data to the blackboard or modifies exist¬ 
ing data. The execution of the entire sys¬ 
tem consists of the asynchronous exe- 
cution of these mod ules. The exe cution of 
v an indi vidual int^giileThoweverTis arriri- 
.ije proc5ss!~Dnce~ a □ 


tivated. it e; 
un til it isTim _ 

"" ^ssociateinft ith each module is a set of 
triggers that~specity tReTromfitions^uadet— interaction 


which that module is activatecfA single 
event, such as the addition ot a particular 
piece of data to the blackboard, could 
cause several triggers to fire at once. The 
determination of which module or mod¬ 
ules should be activated next is done by a 
special module, the Control module. 

It is convenient to introduce a special 
trigger for each module. This trigger deals 
specifically with messages that one module 
may create and send to another. These 
messages are lumped into a separate sec¬ 
tion of the blackboard, the “mailbox.” If 
a message exists in the mailbox for a par¬ 
ticular module, then that module fires and 
is considered for execution. 

Capacity planning expert system ar¬ 
chitecture. The blackboard paradigm pro¬ 
vides the framework for our capacity plan- 


Figure 1. Blackboard paradigm. 


ning expert system. In the following, the 
role of each module in Figure 2 is briefly 
described. It is emphasized that this sec¬ 
tion provides the general framework for a 
capacity planning expert system. Not all of 
the functions described with each module 
need to be included in any particular im¬ 
plementation. 

User module. A distinction must be 
made between the User module and the 
user. The latter refers to the human user of 
the expert system. The former is a piece of 
software that interfaces the user to the 
blackboard. Some of the functions of the 
User module are to determine the purpose 
of the session, the desired amount of user 
the problem-solving pro¬ 


cess, and user guidance in the configura¬ 
tion design process. 

The following three modes of user in¬ 
teraction are appropriate: 

• Analysis. Performance predictions of 
a user-specified configuration with no 
“expert” analysis or interpretation of per¬ 
formance. 

• Evaluation. Evaluation of a user- 
specified configuration; that is, an “ex¬ 
pert” evaluation of performance for a 
particular configuration, but the user is 
responsible for responding to that evalua¬ 
tion and driving the configuration design 
process. 

• Design. Configuration design to a set 
of user-specified requirements and con¬ 
straints; that is, the expert system takes 
control of the design process (with the 
user’s concurrence) by acting on the 


evaluation, updating the configuration, 
recomputing model results, and obtaining 
a new evaluation until a desirable con¬ 
figuration is found. 

The analysis mode provides the func¬ 
tion offered by most current capacity 
planning models. The evaluation mode 
offers a performance assessment, that is, 
a second opinion to the user. The design 
mode exploits the full capability of the 
expert system and is the focus of our 
discussion. 

With the design option, the user has a 
choice concerning the level of interaction 
with the expert system, specifically, 

• None, that is, the system simply 
returns with the final configuration; or 

• Eavesdrop, that is, the user is in¬ 
formed at each step in the design process. 
With the “eavesdrop” capability the user 
is made aware of the problem flow and 
sees various intermediate results. In some 
situations, the user may wish to exercise an 
override capability on the actions taken by 
the expert system. At any point the user is 
able to review and modify any part of the 
problem status, for example, the current 
configuration and work load description. 

Another purpose of the User module is 
to interact with the user, as necessary, for 
guidance and control in the design pro¬ 
cess. For example, a configuration may 
not exist that satisfies the stated perfor¬ 
mance requirements and configuration 
constraints. Once this has been detected, a 
message is sent to the user via the User 
module. The user must then take some ap¬ 
propriate action or terminate the session. 
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Other times an action from the ‘ ‘design ex¬ 
pert” may be treated as optional. For ex¬ 
ample, the performance improvement ex¬ 
pected from a particular configuration 
change may be marginal but necessary in 
order to meet some performance objec¬ 
tive. This action should be applied only 
with the user’s approval. In other situa¬ 
tions, a performance objective (for exam¬ 
ple, response time) may be nearly met, and 
it would be unwise to make a major con¬ 
figuration change without the user’s 
approval. 

Model module. The Model module 
takes a detailed description of the work 
load and the configuration, and produces 
various performance predictions. These 
predictions include response time, 
throughputs, and resource utilizations. 
The Model module displays these perfor¬ 
mance results (or an appropriate subset) to 
the user. This may be displayed either at 
each step in the problem-solving process 
or at its conclusion depending upon the 
level of user interaction. 

To the experienced user, these model 
results are used to detect any deficiencies 
in the current configuration. To the un¬ 
skilled user, they may be little more than 
numbers on a display screen. The model 
implementation and the performance pa¬ 
rameters pertinent to IBM System/38 are 
discussed in the next section. 

Environment module. The Environ¬ 
ment module interacts with the user to 
determine the application work load. The 


user has several levels at which to specify 
this work load, including: 

• application function, e.g., commer¬ 
cial, office; 

• selected application packages; 

• complexity descriptions, e.g., simple 
vs. complex, CPU bound; and 

• measurements. 

The Environment module takes the user 
work load description (at any level) and 
transforms it to the low level charac¬ 
terization required by the model. For bet¬ 
ter accuracy, the “measurements” option 
is taken, when possible. However, for a 
prospective installation or an existing in¬ 
stallation that plans to introduce new ap¬ 
plications, another option must be taken. 

Another function of the Environment 
module is to determine performance ob¬ 
jectives for response time, interactive 
throughput, and batch. A variety of levels 
of interaction with the user may be pro¬ 
vided from which to determine these ob¬ 
jectives. At the lowest level these objec¬ 
tives are input directly by the user. At 
higher levels these objectives may be 
estimated from a general description of 
the customer, for example, business area 
and size. Design guidelines for resource 
utilizations are also established in the En¬ 
vironment module. These guidelines may 
be fixed, for example, a 45 percent disk 
arm utilization threshold; or they may be 
inferred through an interaction with the 
user. This interaction would address 
issues such as the growth potential of the 
customer, the competitiveness of the 
marketing situation, etc. 


Figure 2. Capacity planning expert sys¬ 
tem structure. 


Configuration module. The Configura¬ 
tion module maintains a representation of 
the configuration on the blackboard. For 
the analysis or evaluation options, the user 
is prompted for a configuration descrip¬ 
tion. For the design option, the configura¬ 
tion module must also establish an initial 
configuration from which to start the 
design process. 

The Configuration module responds to 
requests to change the configuration. 
These configuration requests may assign a 
specific value (for example, put 4M bytes 
of memory on the current configuration), 
or increment the current value (for exam¬ 
ple, add 1M byte to the current configura¬ 
tion). These requests for configuration 
changes are made by the user or by the 
Evaluation module through the mailbox 
facility. 

Another function of the Configuration 
module is to determine a set of configura¬ 
tion constraints from the user. Examples 
include constraints on cost, disk storage, 
CPU model, and number of terminals. 
The Configuration module also maintains 
product offering constraints. For exam¬ 
ple, certain disk and memory configura¬ 
tions may not be available with particular 
CPU models. 

If it is determined that a particular con¬ 
straint is preventing the search for a prob¬ 
lem solution from continuing, then the 
Configuration module will inform the user 
by sending an appropriate message to the 
User module. The user must then take 
some action. For example, if a maximum 
cost constraint is specified, it may happen 
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An overdesigned 
configuration meets 
all of the user 
performance 
requirements, but is 
too costly or 
underutilized. 


that no configuration exists that meets 
that constraint. The user must either 
change the performance objectives, the 
cost constraint, or terminate the session. 

Evaluation module. The Evaluation 
module applies its “encoded knowledge” 
to three sets of data. The first set is the 
model output, for example, response time, 
throughputs, utilizations, etc. The second 
is the set of user performance objectives 
for response time and throughput. The 
third set is guidelines on CPU, disk, and 
memory utilization. 

The Evaluation module produces an 
assessment or evaluation of the current 
configuration. This assessment can be 
“satisfactory”; that is, all guidelines and 
objectives are met. Alternatively, the 
evaluation can identify some deficiencies 
in the current configuration along with 
recommendations for changes. 

The Evaluation module is not aware of 
any configuration constraints (either user 
imposed or as a result of the product offer¬ 
ing). Therefore, it may produce a recom¬ 
mended change to the configuration that 
can not be applied. For example, it may 
suggest a faster CPU when the current 
configuration already contains the fastest 
CPU available. The Configuration mod¬ 
ule detects the fact that the configuration 
cannot be changed, and an appropriate 
message is sent to the user through the 
User module. 

The Evaluation module may also pro¬ 
duce more than one change to the current 
configuration with the understanding that 
one or more of these changes, but not 
necessarily all of them, are required. For 
example, it may conclude that either more 
disk arms and/or more main memory is 
required to solve a disk arm utilization 
problem. In the message from the Evalu¬ 
ation to the Configuration module, the 


order in which the changes are to be at¬ 
tempted is specified. In some instances the 
second or third choices are attempted only 
if the constraints, either user or product 
offering, prohibit the first choice. Other 
times all the changes are to be attempted. 
The resources, the amount of change, and 
the change protocol are all passed from the 
Evaluation to the Configuration module 
through the mailbox. 

The changes are not guaranteed to pro¬ 
duce a configuration that will meet all the 
goals. They are, however, changes that in 
the opinion of the Evaluation module will 
move the design closer to a solution. 

The Evaluation module is also able to 
detect “overdesigned” configurations as 
well as those that are “underdesigned.” 
An overdesigned configuration meets all 
of the user performance requirements, but 
is too costly or underutilized. 

The Evaluation module also distin¬ 
guishes between “required” design ac¬ 
tions and ‘ ‘recommended ’’design actions. 
Required actions are a result of some per¬ 
formance objective or utilization guideline 
being significantly violated. Recom¬ 
mended actions, on the other hand, result 
from these items just barely not being met. 
In this case the user is involved (through 
the User module) as to whether or not the 
design action is to be actually applied. 

Control module. The Control module 
directs the execution of the the various 
modules of Figure 2. It performs a match, 
conflict-resolution, and action cycle. 

During the “match” portion of the 
cycle, the Control module determines if a 
module can fire by executing its “triggers.” 
These triggers are conditional tests involv¬ 
ing global data parameters and the ex¬ 
istence of messages in the mailbox for that 
module. 

From all of the modules that can fire 
(the conflict set), the control module picks 
one to execute (conflict resolution). The 
conflict resolution strategy determines 
which module in the conflict set has the 
highest priority. Items that influence this 
priority are a response to a user directive, 
blackboard consistency, and the absence 
of required data on the blackboard. 

When the conflict resolution step has 
completed, the selected module is exe¬ 
cuted (action). In general, the execution of 
a module places messages in the mailbox 
for other modules, as well as adds or 


modifies global data parameters on the 
blackboard. This causes new modules to 
fire on the next cycle. This process con¬ 
tinues until a termination state is reached. 

Execution flow. This section discusses 
some of the key features of the execution 
flow not previously addressed. 

A status flag is associated with each 
global data block (model results, config¬ 
uration, work load, etc.) on the black¬ 
board. An appropriate module is responsi¬ 
ble for maintaining each block of data. 
When a particular status flag is false, the 
corresponding component is triggered. 
The component, once invoked, updates 
the data block and sets the status flag to 
true. For example, if the work load data 
status is false, the Environment module is 
triggered. 

The session is initialized by the Control 
module. All the status flags are set to false. 
Control is then passed to the User module 
at which point the user specifies the pur¬ 
pose for the session, the level of interac¬ 
tion, etc. 

In the “analysis” mode the Environ¬ 
ment, Configuration, and Model modules 
are triggered by virtue of the status flags 
being false. Control is then passed back to 
the User module. The user may request a 
change to the configuration or work load. 
If so, the User module places an ap¬ 
propriate message in the mailbox and the 
change is made. Anytime the Environ¬ 
ment or Configuration modules change 
their respective data blocks, the model 
results status is set to false. This, in turn, 
triggers the Model module. When all pro¬ 
cessing has been completed, control again 
passes back to the User module. The user 
may make additional changes, or termi¬ 
nate the session. 

The flow for the “evaluation” mode is 
similar. The only difference is that the 
Evaluation module is invoked whenever a 
message for it appears in the mailbox or 
the evaluation status is false. Anytime the 
configuration, work load, or requirements 
is changed, the evaluation status is set to 
false. 

In the “design” mode, the Evaluation 
module places a message in the mailbox to 
the Configuration module to change the 
configuration. The message specifies 
which resources to change and by how 
much. It may also send a message to the 
User module to notify the user of the sug¬ 
gested design action (the “eavesdrop” 
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option). The user may accept the action 
or override it. If the configuration is 
changed, the model results and evalua¬ 
tion status are set to false. This will trigger 
the Model and Evaluation modules, and 
so on until a solution is reached. 

In many situations, more than one con¬ 
figuration can be found that meets the 
design goals. This arises when the Evalua¬ 
tion module offers two or more choices for 
a change to the current configuration. For 
example, occasionally it may not be ob¬ 
vious whether to add more memory or ad¬ 
ditional disk arms to address an arm 
utilization problem. The Evaluation 
module orders the changes in its message 
to the Configuration module, say memory 
first then disk arms. 

Taking the first option (more memory) 
will lead the design process through a 
series of configurations to (hopefully) a 
solution. The question then arises as to 
where the design process would have gone 
if the second option (more arms) had been 
taken instead. The system is able to 
‘ ‘backtrack ’ ’ to that choice point and con¬ 
tinue. In some instances the second solu¬ 
tion path may merge with the one tra¬ 
versed to the first solution. Other times a 
new solution may be found along a 
separate path. 

The Configuration module is responsi¬ 
ble for keeping track of choice points, 
which configurations have already been 
evaluated, final configurations, and so on. 
In this way, multiple solutions can be pro¬ 
vided to the user who then makes the final 
determination. 

Performance Expert 
Prototype 

PEP38 is a capacity planning expert 
system for IBM System/38. System/38 is 
a medium-sized computer primarily di¬ 
rected at commercial, office, and business 
applications. It has a number of CPU 
models (currently models 4, 6, 8, 20, and 
40), a range of memory sizes (1 to 16M 
bytes), and 1 to 22 disk arms involving two 
different disks. A large System/38 in¬ 
stallation has well over 100 terminals. 
Batch programs execute concurrently with 
interactive programs. 

The previous section described the 
overall structure for a capacity planning 
expert system and the general capabilities 


Table 1. Workload characterizations required by the model. 

Interactive 

Batch 

instructions per transaction 

instructions per transaction 

disk l/0s at OCR = 0 

disk l/0s at OCR = 0 

disk l/0s at OCR = 1 

disk l/0s at OCR = 1 

disk l/0s at OCR = infinity 

disk l/0s at OCR = infinity 

percent asynchronous writes 

percent asynchronous writes 

working set size 
terminal keying/think time 

working set size 




of its constituent components. This pro¬ 
vides the basis for PEP38. 

PEP38 has been implemented on 
VM/SP under the CMS operating system. 
A variety of tools and languages available 
on VM have been used. The Model 
module is written in APL; the Environ¬ 
ment and User modules in Pascal; the 
Control module in REXX (a CMS com¬ 
mand language); and the blackboard as 
CMS files. Implementations of the Con¬ 
figuration module have been developed in 
Pascal and ESE/VM. 11 Each tool or lan¬ 
guage was chosen for its suitability in im¬ 
plementing the function of a particular 
module. 

Versions of the Evaluation module have 
been written in ESE/VM, LISP, 12 and 
OPS5. 13 These different implementations 
allowed us to assess the relative merits of 
each tool for this application. Due to the 
modular nature of the blackboard struc¬ 
ture, the different versions were easily in¬ 
terchanged. 

A variety of levels are available to the 
PEP38 user for describing the application 
work load: measurements from an existing 
installation, complexity descriptions (sim¬ 
ple, medium, and complex), and selected 
application packages. A combination of 
these characterizations can be used to 
describe the installation work load (either 
real or projected). 

Table 1 shows the model level work load 
characterization to which these higher 
level descriptions must map. For interac¬ 
tive programs, a transaction corresponds 
to one interaction between the terminal 
and the system. A batch transaction 
represents a user-defined measure of batch 
work. Of particular note is the manner in 
which the disk I/O activity is charac¬ 
terized. System/38 provides a “single level 
store” architecture in which all data (per¬ 


manent and temporary) and programs 
(system and application) are mapped per¬ 
manently into the system’s virtual address 
space. As such, all disk reads are paged 
(demand or prefetch) and disk writes are 
page outs (either as a result of page frame 
stealing or page purges). Some portion of 
the writes are “asynchronous”; that is, 
they are not in line with transaction 
response time. 

The number of disk I/Os per trans¬ 
action is a function of the memory over¬ 
commitment ratio, or OCR. The OCR is 
the sum of the active tasks’ working set 
sizes divided by the amount of real 
memory available for their execution. 
Paging rate curves of this form are com¬ 
monly used in the performance analysis of 
virtual storage systems. 9 

The assumed form of the paging curve is 

n = (a + br k )/{\ + cr k ) 
where n is the number of I/Os per trans¬ 
action, r is the OCR, and a, b, c, and k are 
application-dependent parameters. The 
coefficients a, b, and c can be easily ex¬ 
pressed in terms of n 0 , n i, and /z inf , the 
number of disk I/Os at OCRs of 0,1, and 
infinity, respectively. 

The configuration parameters include 
the CPU model, disks, memory size, and 
terminals. System/38 supports other I/O 
devices such as tapes and printers, and 
allows for the attachment of many com¬ 
munications lines. These I/O devices and 
communication lines have not been in¬ 
cluded in the current version of PEP38. 
For convenience, the number of batch ini¬ 
tiators is classified as a configuration pa¬ 
rameter. The Configuration module main¬ 
tains the constraints that reflect valid 
marketing configurations. The user is able 
to specify additional constraints on the 
CPU model and bounds on the number of 


July 1986 


47 














The Evaluation 
module examines the 
model results in view 
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terminals. The ability to specify cost con¬ 
straints has not yet been implemented. 

The model is based on a set of mean- 
value queuing equations. 14-16 Two classes 
of jobs (batch and interactive) are al¬ 
lowed. Contention is modeled for main 
memory, the CPU, and the disk arms. The 
CPU is modeled as a preemptive-resume 
priority single server. The disk arms are 
modeled as “first-come-first-served” 
single servers. In System/38, interactive 
and batch typically execute in separate 
memory partitions. Contention for the in¬ 
teractive partition is approximated by a 
multiserver, the number of servers is the 
multiprogramming level, and the service 
time is the sum of the CPU and disk 
response times per transaction. The size of 
the batch partition is set to accommodate 
all of the active batch initiators, so that no 
contention exists among batch jobs for the 
batch multiprogramming level. Further¬ 
more, the OCR for batch with this ar¬ 
rangement is one. 

A typical set of model results from 
PEP38 is given in Table 1. 

The response time is broken down into 
its constituent parts: CPU, disk, and 
memory. The CPU and disk response time 
components given a large amount of 
memory (OCR = 0) are also provided. At 
OCR = 0, the number of disk I/Os per 
transaction (equal to n 0 ) and the CPU 
paging overhead are minimal. These 
values are used by the Evaluation module 
to assess the effectiveness of adding more 
memory as opposed to adding either a 
faster CPU or more Disk arms to remove a 
performance bottleneck. The interactive 
throughput is given in transactions per 
hour. Batch performance is measured in 
transactions per second and a “degrada¬ 
tion.” The degradation is the ratio of a 


batch program’s stand-alone execution 
time to that in a contention environment. 
Utilizations are provided for CPU and 
Disk arms, including both the interactive 
and batch contributions. Utilizations are 
also provided under an assumption of a 
large amount of main memory. 

The Evaluation module examines the 
model results in view of a set of user per¬ 
formance objectives and design guide¬ 
lines. The result is an assessment of the 
current configuration. This assessment 
can be that the configuration meets its 
requirements, that is, a solution. Alter¬ 
natively, it can be that the current con¬ 
figuration is deficient. In this case rec¬ 
ommendations are made to change the 
configuration in an attempt to move it 
closer to a solution. 

The Evaluation module is implemented 
using techniques similar to many other ex¬ 
pert system applications. The knowledge 
is represented as a set of “if-then” rules 
(currently around 120). These rules are 
separate from a control or inference struc¬ 
ture, which directs the way in which this 
knowledge is applied. 

A configuration is evaluated and classi¬ 
fied into one of four categories. The first is 
where all the user performance objectives 
on response time and throughput are satis¬ 
fied, and the utilizations all fall within 
desired ranges. The second category is 
where the configuration is clearly defi¬ 
cient. This occurs when response time 
and/or throughout objectives are not met 
by a wide margin and/or resource utiliza¬ 
tions exceed threshold values. In this case, 
a change to the current configuration is 
definitely required. The third is where the 
configuration is marginal; that is, not all 
the objectives and/or guidelines are met, 
but they are not greatly exceeded either. In 
this case, changes to the configuration oc¬ 
cur only with the user’s approval. The last 
category is where the configuration is 
overdesigned. In this case a less expensive 
configuration can be found that will satis¬ 
fy all of the performance requirements. 
Again, changes are made only with the 
user’s approval. 

The evaluation rules are grouped into 
categories that deal separately with 
throughput, response time, and utiliza¬ 
tions. “Throughput rules” exist for both 
batch and interactive. They seek to deter¬ 
mine whether the computed throughput is 
“excessive,” “too small,” or “satisfac¬ 


tory” relative to the objective. If no 
throughput objective has been provided or 
if the computed throughput lies in the 
range of 1 to 1.2 times the objective, then 
the throughput is considered satisfactory. 
Computed throughputs less than the ob¬ 
jective or greater than 1.2 times the objec¬ 
tive are considered too small or excessive, 
respectively. 

“Interactive response time” rules look 
at the computed response time relative to 
the objective, if any. Computed values less 
than the objective are “satisfactory”; val¬ 
ues in the range of 1 to 1.2 times the objec¬ 
tive are “marginal”; and values greater 
than 1.2 times the objective are “unac¬ 
ceptable.” Computed response times less 
than 0.75 times the objective cause the 
Evaluation module to explore the possi¬ 
bility of an overdesigned configuration. 
A similar set of rules apply to batch 
degradation. 

Three different critical values are used 
in the CPU and Disk utilization rules: the 
threshold, the guideline, and the mini¬ 
mum. Utilizations above the threshold 
(for example, 0.50 for Disk arms) are 
“unacceptable.” Utilizations between the 
guideline (for example, 0.45 for Disk 
arms) and the threshold are “marginal.” 
Utilizations less than the minimum value 
(for example, 0.20 for Disk arms) produce 
an “overdesigned” configuration. The re¬ 
maining range (between the minimum and 
the guideline) are “satisfactory.” We note 
that due in large part to the System/38 
single-level storage architecture, the Disk 
arm utilizations are nearly balanced. Simi¬ 
lar ranges exist for the memory OCR. 

The limits cited above were derived 
from experienced System/38 performance 
analysts. They reflect generally accepted 
guidelines for assessing System/38 perfor¬ 
mance in the field. 

The following are typical rules: 

• if 

“interactive throughput objective is 
specified” 

and “computed throughput is less than 
1.2 times the objective” 
and 

“computed throughput is greater 
than or equal to the objective” 

then 

“interactive throughput objective is 
satisfied” 
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• if 

“response time objective is speci¬ 
fied” 
and 

“computed response time is greater 
than 1.2 times the objective” 

then 

“response time objective is greatly 
exceeded” 

Once a problem has been detected and 
its severity established, additional rules 
exist to determine the configuration 
resource or resources that should be 
changed to solve the problem. For exam¬ 
ple, response time problems may be solved 
by either a faster CPU (to reduce CPU ser¬ 
vice time and contention), more Disk arms 
(to reduce arm contention), or more 
memory (to reduce the number of Disk 
I/Os and CPU overhead). A variety of 
rules exist that look at the various com¬ 
ponents of the response time (see Table 2) 
and determine the most appropriate ac¬ 
tion. A similar situation exists for utiliza¬ 
tion and throughput problems, both in¬ 
teractive and batch. 

Typical rules are 

• if 

“Disk arm utilization is unaccept¬ 
able” 
and 

“Disk arm utilization with OCR = 0 
is less than guideline” 

then 

“add more memory to the current 
configuration” 


• if 

“response time objective is greatly 
exceeded” 
and 

“CPU response time component is 
less than objective” 
and 

“Disk response time component is 
less than objective” 
and 

“response time with OCR = 0 is less 
than objective” 
and 

“Disk utilization is significant 
(greater than 0.25)” 
and 

“CPU response component is less 
than 0.5 times Disk response” 
and 

“memory OCR is acceptable” 

then 

“first choice to add Disk arms, sec¬ 
ond is to add more memory” 


Table 2. PEP 38 model results. 


Interactive 


Response time 185 

CPU -52 

CPU (OCR = 0) .45 

Disk 1-33 

Disk (OCR - 0) .83 

Memory -00 

Throughput 6400 

Batch 

Throughput 9.40 

Degradation -55 


Utilizations 

CPU .61 

Interactive .48 

Interactive (OCR = 0) .45 

Batch 13 

Disk .51 

Interactive -44 

interactive (OCR = 0) .32 

Batch -08 

Memory 

Interactive Partition 

Size (MB) 6.0 

MPL 15 

OCR 1.57 

Batch Partition 

Size (MB) .5 

MPL 1 


In the “design” mode, the amount of 
change to a resource is also calculated. The 
Evaluation module produces an explana¬ 
tion for a particular design action. These 
are output to the user (using the eavesdrop 
option) by a message to the User module 
through the mailbox. The following are 
typical explanations: 

“a faster CPU is required because the 
interactive component of the CPU 
utilization exceeds its threshold of 
70%” 

“more terminals are required because 
the interactive throughput does not 
meet its objective of 6000 trans¬ 
actions per hour” 

“More Disk arms and/or main mem¬ 
ory is recommended because the Disk 
arm utilization (including the paging 
overhead) exceeds its guideline of 
45%” 

A control strategy represents how the 
rules are used to solve a problem, and is 
separate from the rules themselves. A suc¬ 
cessful strategy used in PEP38 first checks 
to see if the throughput is “excessive” 
(using the throughput rules). If it is, the 
design action is “remove terminals or 
batch initiators from the configuration.” 
Unacceptable response time situations (in¬ 
cluding batch degradation) are investi¬ 
gated next followed by unacceptable 
utilizations. Each step invokes an ap¬ 
propriate group of rules. If necessary, con¬ 


figuration changes (to the CPU, Disks, 
and/or memory) are generated by the 
Evaluation module and sent to the Con¬ 
figuration module. Inadequate through¬ 
puts are addressed next followed by 
marginal response times and utilizations. 
Finally, the possibility of an overdesigned 
configuration is explored. 

T his article has described the applica¬ 
tion of expert system technology to 
the capacity planning problem. The 
role of an expert system to improve the 
usability of performance prediction 
models has been discussed. A structure has 
been presented that identifies the key com¬ 
ponents of the capacity planning process 
and upon which expert system implemen¬ 
tations can be based. Finally, some details 
of PEP38, a capacity planning expert sys¬ 
tem for the IBM System/38, have been 
provided. 

Our experiences with PEP38 have led us 
to several conclusions. The “expertise” 
required to use a performance prediction 
model effectively in the configuration 
design process can be captured and en¬ 
coded into a knowledge base. 

The rule-based approach to represent¬ 
ing this knowledge and the separation of 
knowledge from control has proved very 
beneficial in the development process. The 
authors generally agreed on “what” the 
appropriate rules were to analyze the 
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model results. They differed, however, on 
“how” this knowledge was to be applied. 
For example, whether one analyzed a con¬ 
figuration by first looking at utilizations 
before response times or vice versa was a 
matter of personal preference. Subtle dif¬ 
ferences in the control strategy also arose 
in dealing with response time/throughput 
interactions. With the “declarative” 
nature of an expert system approach, it 
was very easy to change control strategy to 
suit an individual’s preferences without 
any impact to the knowledge base. 

Our experiences also demonstrate the 
need for ‘ ‘expert systems ” to be integrated 
with more conventional programs. For ex¬ 
ample, the performance prediction model 
is a conventional, procedural APL pro¬ 
gram that uses no “rule-based” concepts. 
It is very important to have an overall 
design structure for the system (for exam¬ 
ple, the blackboard), and to use the most 
appropriate language or tool for each of its 
components. The knowledge-intensive 
components (for example, the Evaluation 
module) are viewed on an equal basis with 
the more conventional components. 

There was a tendency to include too 
much information into a single evaluation 
rule. A “complex” rule contained the en¬ 
tire set of conditions necessary to produce 
a particular conclusion. This approach, 
however, caused problems when new rules 
were added, old rules were modified, or 
the control structure was changed. After a 
couple of false starts, it was determined 
that each rule needed to be quite simple. 

Finally, we shared many of the same ex¬ 
periences of other expert system builders 
relative to the “shell vs. language” issue. 
Shells (for example, ESE/VM) are very 
convenient, productive tools for im¬ 
plementing a knowledge base and control 
structure. In some instances, however, 
they lack the desired flexibility provided 
by a programming language (for example, 
LISP). The choice of the particular tool to 
implement the knowledge base and con¬ 
trol structure is not nearly as critical as a 
good overall design structure for the 
system. 

Capacity planning is just part of the per¬ 
formance management problem. Tuning, 
application design, operations, etc., are 
other equally important components of 
performance management. Future work 
will address these areas in the context of 
the expert system structure that has been 
started here. □ 


References 

1. J. McDermott,“Rl: A Rule-Based Con¬ 
figurer of Computer Systems,” Artificial 
Intelligence, Vol. 19, No. 1, pp. 39-88. 

2. J. H. Griesmer et al„ “YES/MVS: A 
Continuous Real Time Expert System,” 
Proc. Nat‘l Conf Artificial Intelligence, 
Austin, Texas, Aug. 1984, pp. 130-136. 

3. J. Kornell, “A VAX Tuning Expert Built 
Using Automated Knowledge Acquisi¬ 
tion,” IEEE 1984 Computer Society 
Conf. Artificial Intelligence Applications, 
Denver, Colo., Dec. 1984, pp. 38-41. 

4. J. L. Hellerstein and H. Van Woerkom, 
“YSCOPE: A Shell for Building Expert 
Systems for Solving Computer-Perfor¬ 
mance Problems,” CMC ’85 Conf, 
Dallas, Texas, Dec. 1985, pp. 170-180. 

5. H. P. Artis, “Using Expert Systems for 
Analyzing RMF Data,” CMC ’85 Conf, 
Dallas, Texas, Dec. 1985, pp. 653-657. 

6. A. P. Levine, “ESP: An Expert System 
for Computer Performance Manage¬ 
ment,” CMC ‘85 Conf, Dallas, Texas, 
Dec. 1985, pp. 181-186. 

7. L. Bronner, “Overview of the Capacity 
Planning Process for Production Data 
Processing,” IBM Systems J., Vol. 19, 
No. 1, 1980, pp. 4-28. 

8. D. C. Schiller, “System Capacity and Per¬ 
formance Evaluation,” IBM Systems J., 
Vol. 19, No. 1, 1980, pp. 46-67. 

9. D. Ferrari, Computer Systems Perfor¬ 
mance, Prentice-Hall Inc., Englewood 
Cliffs, N.J., 1978. 

10. L. D. Erman et al., “The Hearsay-II 
Speech Understanding System: In¬ 
tegrating Knowledge to Resolve Uncer¬ 
tainty,” Computing Surveys, Vol. 12, No. 
2, June 1980, pp. 213-253. 

11. ESE/VM General Information Manual, 
Document No. GH20-9597, IBM Corp. 

12. LISP/VM User’s Guide, Document No. 
SH20-6477, IBM Corp. 

13. C. L. Forgy, OPS5 User’s Manual, tech, 
report, Carnegie-Mellon University, 
Dept, of Computer Science, 1981. 

14. M. Reiser and S. Lavenburg, “Mean 
Value Analysis of Closed Multichain 
Queuing Networks,” JACM, Vol. 27, 
No. 2, April 1980, pp. 313-322. 

15. Y. Bard, “Some Extensions to Multiclass 
Queuing Network Analysis,” Proc. 4th 
Int’l Symp. Modeling and Performance 
Evaluation of Computer Systems, North 
Holland, Amsterdam, 1979. 

16. R. M. Bryant et ah, “The MVA Pre-empt 
Resume Priority Approximation,” Conf. 
Measurement and Modeling of Computer 
Systems, Minneapolis, Minn., Aug. 
29-31, 1983, pp. 12-27. 



Gary J. Stroebel received his BS, MS, and PhD 
degrees in engineering mechanics and mathe¬ 
matics from the University of Minnesota in 
1965, 1967, and 1969, respectively. 

Since 1969 Stroebel has worked for the IBM 
Corporation. He is currently manager of an ad¬ 
vanced technology group that is applying expert 
systems to the development, usability, and sup¬ 
port of computer systems. Other areas of 
research interest include performance modeling 
and operating systems design. He is a member 
of ACM and AAAI. 



Randy D. Baxter received his BS in computer 
science from the University of Wisconsin- 
Oshkosh in 1981. Since 1981 he has worked for 
the IBM Corporation. He is currently a staff 
programmer working on expert system tools 
and applications. Previously he was involved in 
the development of modeling techniques for 
hardware and software reliability prediction. 
He is a member of the IEEE Computer Society 
and AAAI. 



Michael J. Denney received his BS degree in 
computer science in 1982 from Iowa State 
University. He joined the IBM Corporation in 
Rochester, Minnesota in 1982. He has worked 
primarily in the areas of system performance 
analysis, work load characterization, and per¬ 
formance modeling. 


Readers may write to Stroebel at IBM Corp., 
Dept. 43L, Highway 52, 37th St., NW, Roch¬ 
ester, MN 55901. 


50 


COMPUTER 












^ IEEE Computer Society Symposium on 


OFFICE AUTOMATION 

— Integration, Interconnection, and 
Use of Personal Computers 


April 27-29, 1987 
National Bureau of Standards 
Gaithersburg, MD 


Sponsored by 

The IEEE Computer Society Technical Committee 
on Office Automation 

The Technical Committee on Personal Computing 
The Institute for Computer Sciences and Technology 
of the National Bureau of Standards 


As we enter the second decade of office automation and personal computing, we ask ourselves where all the 
recent technologies lead us. While continued progress in the hardware, application, and system technologies 
is anticipated, the R&D trend seems to be spearheading towards system integration, distributed services, 
and knowledge engineering. Advances in these & other areas will elevate office automation to a new plateau. 
This symposium provides a forum for the researchers and practitioners to present their results & views, 
and discuss problems and directions for the future electronic office. 


Suggested topics: 

Information management systems 
Communication, LAN 
Multi-user workstation 
Architecture & standards 
Distributed systems & applications 
Procedure automation 
□ffice/DP integration 
Multi-media & decision support 
Composition languages 
Office publishing systems 
I/O and user interface technologies 
Al & expert systems 
Management control and security 
Organizational and social factors 
Requirements analysis 
Software engineering 

How to submit: 

Original papers of up to 5000 words C20 double¬ 
spaced pages] are invited on topics included in Cbut 
not restricted to] the above list. Submitted papers 
will be refereed by the Program Committee. Accepted 
papers wil be published in the Conference Proceed¬ 
ings. Authors of accepted papers will be expected 
to sign an IEEE copyright release form. Proposals 
for panel discussions are also solicited. 

Please send FOUR C4] copies of the paper and 
abstract to: 

Dr. David M. Choy 

IBM Almaden Research Center 

650 Harry Road, Dept K52/803 
San Jose, California 95120-6099 
[408] 927-1846 [dmc@ibm-sj,arpa] 

Important Dates: 

Paper due: September 15, 1986 

Notification of Acceptance: November 15, 1986 
Final Copy due: January 15, 1987 

Conference: April 27-29, 1987 


Conference Chair: 

Vincent Y. Lum 

Naval Postgraduate School 

Conference Co-chair: 

Lynne Rosenthal 

National Bureau of Standards 

Program Chair: 

□avid M. Choy 

IBM Almaden Research Center 

Program Co-chair: 

S. Bing Yao 
University of Maryland 

Treasurer: 

Amit Basu 

University of Maryland 

Publicity: 

□etlev Ruland 

IBM Almaden Research Center 

Local Arrangements: 

Elizabeth G. Parker 
National Bureau of Standards 
Program Committee: 

Robert B. Allen, Bell Communications Research, 

New Jersey 

Federico Barbie, IBM Almaden Research Center, 
California 

Giampio Bracchi, Politecnico di Milano, Italy 
Donald □. Chamberlin, IBM Almaden Research Center, 
California 

Peter Chen, Louisiana State University and M.l.T. 

Peter Dadam, IBM Heidelberg Scientific Center, Germany 
Clarence A. Ellis, Microelectronics and Computer 
Technology Corp., Texas 

Christos Faloutsos, University of Maryland, Maryland 
Amelia Fong Lochovsky, University of Guelph, Canada 
Frederick H. Lochovsky, University of Toronto, Canada 
Najah Naffah, Bull Transac, France 
Elizabeth G. Parker, National Bureau of Standards, 
Maryland 

□etlev Ruland, IBM Almaden Research Center 
Dennis Tsichritzis, Centre Universitaire d’lnformatique, 
Switzerland 

C. Thomas Wu, Naval Postgraduate School, California 
Roberto Zicari, Politecnico di Milano, Italy 





CALL FOR PAPERS 



Sixth Symposium on Reliability 
in Distributed Software 
and Database Systems 


SPONSORS 

IEEE Computer Society @ 

TC on Distributed Processing 
TC on Fault-Tolerant Computing 

CO-SPONSORS IN COOPERATION WITH 


March 17-19,1987 
Hilton Conference Center 
Kingsmill - Williamsburg, Virginia 


NASA-Langley Research Center 
College of William and Mary, Computer Science Department 
Williamsburg, Virginia 


The theme of this symposium is reliability in distributed systems including 
distributed applications, distributed operating systems, and distributed 
databases. 

Papers that address increased availability in error-prone environments, as 
well as security, are especially sought. Papers covering performance studies 
of reliability techniques and experiences with error-prone environments are of 
special interest. 


TOPICS OF INTEREST 

■ Reliable Distributed Software Systems 

• Communication primitives for reliable distributed computing 

• Techniques for non-stop operations 

• Decentralized control 

• Software fault tolerance including error confinement, graceful 
degradation, and system reconfiguration and restart 

• Distributed operating systems 

• Performance studies of reliability techniques 

• Security in distributed applications 

■ Reliable Database Systems 

• Integrity and consistency 

• Robust concurrency control 

• Fault tolerant distributed databases 

• Experiences with testbeds and real-world distributed databases 

• Performance studies of reliability techniques 

• Security in databases 


Dr. Edwin C. Foudriat, NASA LaRC, 

Hampton, VA 

Dr. Larry Wittie, SUNY - Stony Brook, NY 

Dr. William Bynum, College of William and 

Mary, Williamsburg, VA 

Dr. Dharma Agarwal, North Carolina State 

University, Raleigh, NC 

Dr. S. K. Shrivastava, University of Newcastle 

-Upon-Tyne, GB 


Tutorial Chairman: 


PROGRAM COMMITTEE 

■ Dr. Jean-Pierre Banatre; IRISA/INSA; Universite de Rennes; France 

■ Dr. Kenneth P. Birman; Dept, of CS; Cornell Un.; Ithaca, NY 

■ Dr. David Cohen; Teknekron Infoswitch; Richardson, TX 

■ Dr. Robert Paul Cook; Department of CS; Un. of Virginia; Charlottesville, VA 

■ Dr. David DeWitt; Dept, of CS; Un. of Wisconsin; Madison, Wl 

■ Dr. Carla Ellis; Dept, of CS; Un. of Rochester; Rochester, NY 

■ Dr. Jim Gray; Tandem Computers; Cupertino, CA 

■ Dr. Richard Le Blanc; School of Information and Computer Science; Georgia 
Institute of Technology; Atlanta, GA 

■ Dr. Sape Mullender; Amsterdam Math Center; The Netherlands 

■ Dr. Daniel Reed; Dept, of CS; Un. of Illinois at Urbana-Champaign; Urbana, IL 

■ Dr. Richard Schlichting; Dept, of CS; Un. of Arizona; Tucson, AZ 

■ Dr. Ray Strong; IBM Almaden Research Center; San Jose, CA 

■ Dr. Liba Svobodova; IBM Research Labs. - Zurich, Switzerland 

PAPER SUBMISSION 

Four (4) copies of the manuscript should be submitted to: 

Dr. Larry Wittie, Program Chair 
Computer Science Department 
State University of New York—Stony Brook 
Stony Brook, NY 11794-4400 

by September 1,1986. Authors will be notified by October 15,1986. 

Final camera-ready copies available by December 15,1986. 


Proposals for one day tutorials are solicited in the areas related to the topics 
of interest. Proposals should be submitted to the Tutorial Chair by 
September 1,1986. Contact with the Tutorial Chair regarding proposal 
information and scheduling is suggested. 


AWARDS 

A monetary award of $1,000 for the best paper will be made. 












— 





Sarosh N. Talukdar, Eleri Cardozo, and Luiz V Leao 
Carnegie-Mellon University 


July 1986 


E lectric power systems work under 
two sets of constraints. 1 The first 
set of constraints, called load con¬ 
straints, reflects the contractual agree¬ 
ments of the system to supply its cus¬ 
tomers with electric energy. The second, 
called operating constraints, imposes up¬ 
per and lower limits on the voltages, cur¬ 
rents, and other variables in the system. 

Power systems have three major 
operating states: normal, emergency, and 
restorative. A system is in a normal state 
when both its load and operating con¬ 
straints are met. It is in an emergency state 
when there are major violations of the 
operating constraints. It is in a restorative 
state when only the load constraints are 
violated. 

Transitions from normal to emergency 
states are caused by disturbances which 
are of two types: scheduled and random. 
Examples of the former are diurnal 
changes in energy demands and outages of 
equipment for routine maintenance. Ex¬ 
amples of the latter are lightning strokes to 
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transmission lines. When the likelihood of 
transitions to emergency states is low, the 
system is said to be secure. 

The typical, large power system is run 
from three to six consoles located in a 
facility called an energy control center. 
The consoles are supported by a computer 
system that is connected to networks of 
distributed sensors and actuators. The 
computer system represents a significant 
investment ($5 million to $50 million) and 
contains several processors that run 
customized software written mainly in 
Fortran and assembly languages. The 
computer system’s principal functions are 
the collection, management, analysis, and 
display of data in real time. The computer 
system’s prescriptive capabilities are 
limited to relatively low-level automatic 
control algorithms. Planning and other 
high-level decision making is left entirely 
to the human operators. In particular, the 
operators are responsible for 

• Normal control. This means steering 
the system along a trajectory that main- 
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tains a good balance between two conflict¬ 
ing objectives—minimizing operating cost 
and maximizing security. Automatic pro¬ 
grams (called economic dispatchers) are 
available to minimize cost but do not con¬ 
sider security. Other programs can simu¬ 
late the effects of disturbances. The 
operators must examine the simulation 
results, infer the security level of the sys¬ 
tem, design strategies to improve the 
security if necessary, and translate these 
strategies into instructions to the ac¬ 
tuators. 

• Alarm processing and crisis manage¬ 
ment. A sudden disturbance can cause 
waves of alarms to radiate outwards from 
the site of the disturbance. A single distur¬ 
bance can produce hundreds of alarms. 
Some of these can be false. Nevertheless, 
operators must quickly identify the ini¬ 
tiating disturbance, diagnose what has 
happened to the system, and take correc¬ 
tive action. 

• Restorative control. This refers to the 
process of reenergizing and reconnecting 
the parts of a system that have lost supply 
during a crisis. 

Difficulties. Operators often suffer 
from information overload, particularly 
during times of crisis. Another difficulty is 
that the operators’ functions are knowl¬ 
edge intensive. Much of this knowledge 
can, and usually is, compiled into manuals 
and reports. But this is not the most conve¬ 
nient form for it. Operators learn best 
from experience and do best what they are 
most familiar with. They are at their worst 
in unfamiliar situations. But it is the infre¬ 
quent and therefore unfamiliar situations 


that can be the most dangerous. A major 
blackout and the period of restoration that 
follows constitute an extreme example. An 
operator seldom experiences more than 
one such event in a lifetime. 

Besides knowledge, the operators need 
considerable diagnostic and planning 
skills. Expert operators perform much 
better than novices. But even experts often 
make mistakes. 

The trend for the future is towards more 
complex operating problems. The decision 
space is expanding to include such emerg¬ 
ing technologies as alternate generation 
and demand-side management. Also, 
socioeconomic and environmental pres¬ 
sures are causing power systems to be 
operated under continually tightening 
constraints. 

The functions of an assistant. In¬ 
telligent, computer-based assistants could 
go a long way towards relieving the dif¬ 
ficulties faced by operators. In particular, 
intelligent assistants could help in the 
following areas: 

• Abstraction: to summarize results, 
thereby reducing the information loads on 
operators. Alarm processing 2 is an exam¬ 
ple of an area that could benefit from this 
activity. 

• Intelligent monitoring: to recognize 
circumstances that should be called to the 
operators’ attention. 

• Historical reviews: to check the past 
operations of a system to see if they con¬ 
tain information useful to existing cir¬ 
cumstances. 

• On-line referencing: to search the 
operators’ manuals and display the por¬ 
tions relevant to existing circumstances. 

• Diagnosis: to deduce what happened 
and why, when sudden transitions in a 
power system occur. 

• Criticism: to provide operators with 
constructive critiques of the actions they 
plan. 

• Planning: to provide advice and to 
help formulate plans for activities such as 
system restoration and inter-utility power 
exchanges. 

• Training: to tutor operators in the 
skills they need. 

• Intelligent interfaces: to provide the 
means for operators to communicate with 
the computer system in natural and easy 
ways. 

Types of assistants. We recognize two 
types of assistants. The first, called 


Phase-1 assistants, are for off-line uses, 
particularly research, proof-of-concept, 
and training. The second, called Phase-2 
assistants, will evolve from Phase-1 
assistants and be used in on-line applica¬ 
tions in energy control centers. 

The full range of functions for either 
type of assistant is too wide to be accom¬ 
modated in a single program. Instead, dis¬ 
tributed problem solving (DPS) ap¬ 
proaches are needed. (By “DPS” we mean 
multiple, cooperating programs sharing 
raw and/or processed data.) 

The DPS features that we feel are essen¬ 
tial for Phase-1 assistants are 

• the ability to accommodate a society 
of expert systems 3 so that disparate 
domains of human expertise can be 
included, 

• the ability to accommodate number¬ 
crunching programs to handle the 
numerically intensive tasks of power 
system analysis, 

• multilingual capabilities so each pro¬ 
gram can use a language that suits its 
purposes and ancestry, 

• expandability so the assistant can 
begin with a modest set of programs 
that can be expanded later, and 

• distributed processing for speed, 
reliability, and flexibility. 

In addition to these features, a Phase-2 
assistant must be designed so it can be con¬ 
nected to an existing energy control system 
with a minimum of disruption. Also, it 
must be sufficiently fast and reliable for 
real-time use. 

An overview of Toast 

Toast is a Phase-1 assistant that runs in a 
network of time-shared VAX 11/780’s 
and 11/750’s. It has a modest but expand¬ 
able library of programs that execute in an 
environment for distributed problem solv¬ 
ing called Cops. This environment pro¬ 
vides a number of facilities for construct¬ 
ing Phase-1 assistants. Among these are 
the means for assembling blackboards. 4-6 
(We use the term “blackboard” to mean a 
database for messages.) Problem-solvers 
(human or programmed) can commu¬ 
nicate by writing on and reading from such 
blackboards. For instance, Problem- 
solver-A may post a message asking for 
help in analyzing a linear circuit. Problem- 
solver-B may respond with an offer of 
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help. Then Problem-solver-A can post a 
message describing the circuit to be 
analyzed, and so on. 

The main advantages of blackboards 
are extensibility and flexibility. New prob¬ 
lem solvers can be added merely by giving 
them access to a blackboard. The type of 
access determines their roles. They may be 
allowed complete autonomy (being per¬ 
mitted to read and write messages when¬ 
ever they feel like it) or required to inter¬ 
rupt whatever they are doing in order to 
respond to certain types of messages. 
Some problem solvers may be allowed to 
issue commands and take on supervisory 
roles. Others may be made subservient to 
any degree to one or more supervisors. 

Toast contains two blackboards and a 
library of programs, as shown in Figure 1. 
These programs are described below. 

The Diagnostician is a rule-based expert 
system for trouble analysis. Given the ini¬ 
tial and final configurations of a power 
network, it hypothesizes the causes of the 
transition. The Discrete Event Simulator 
is a rule-based program that knows how 
power systems’ protection schemes work. 
Given the initial configuration of a power 
network and a disturbance, it predicts the 
train of events that would result. To exe¬ 
cute several simulations in parallel, the 
Concurrent Simulator allocates machines 
to run copies of the Discrete Event Simu¬ 
lator and transfers the results back to the 
main blackboard. The Blackboard Mon¬ 
itor is a rule-based kernel that maintains 
its blackboard and controls access to it. 
Finally, the User Interface is a rule-based 
program with the obvious purpose of giv¬ 
ing a human access to the main black¬ 
board. 


Cops (a Concurrent 
Production System) 

Functionally, Cops is an environment 
for assembling distributed problem solv¬ 
ing organizations from independent ex¬ 
pert systems and other programs. Struc¬ 
turally, Cops is a superset of the OPS5 
language. 7 OPS5 was chosen because it is 
stable, well documented, readily available, 
and perhaps the most widely used lan¬ 
guage for writing expert systems. Cops is 
designed to run in a network of VAX com¬ 
puters under UNIX 4.2. 




Figure 2. An OPS5 program. 


An overview of OPS5. An OPS5 pro¬ 
gram has three components: Working 
Memory (WM), Production Memory 
(PM), and an Inference Engine (IE). 

Working Memory is a global database in 
which a description of a problem is stored 
and the solution to the problem evolves. 

Production Memory contains general 
knowledge about a problem area. This 
knowledge is encoded in productions 
(rules). A production consists of a condi¬ 
tion-action pair. The conditions describe 
patterns that may occur in WM. Most of 
the permissible actions alter the WM. Ex¬ 
amples are make (create a new element in 


WM), modify (change an element), and 
remove (delete an element). 

The Inference Engine repeatedly applies 
the contents of PM to WM (Figure 2). 
Each cycle of this application has the 
following steps: 

• Match. The Inference Engine deter¬ 
mines the set of rules whose left-hand sides 
(conditions) are satisfied by the current 
contents of WM. This set is called the 
conflict-set. 

• Select. The Inference Engine selects 
one rule from the conflict-set by making 
use of some fairly simple criteria. 

• Act. The Inference Engine performs 
the actions specified by the selected rule. 
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Figure 3. Two programs in Cops. 


The cycle continues until the contents of 
WM reach a state for which there are no 
more applicable rules or until a halt is exe¬ 
cuted. Thus, the OPS5 execution cycle is 
while not halt 
match 

if conflict-set is empty 
then halt 
else select a rule 


An overview of Cops. Cops extends 
OPS5 by allowing the Inference Engine of 
one program to modify the Working 
Memory of another by the asynchronous 
delivery of messages (Figure 3). This is 
done by adding two actions to OPS5’s list, 
namely, send (which is equivalent to a 
remote make) and wait (which suspends a 
program’s execution until a message ar¬ 
rives). Thus, the cycle of the Cops In¬ 
ference Engine is: 

while not halt 

accept pending messages 
update Working Memory 
match 

if conflict-set is empty 
then wait for messages 
else select a rule 

Cops also allows each program to clone 
itself or another program, select a com¬ 
puter from among those available, and set 
the clone to running in it. To help in doing 
this, it provides some process management 
functions (such as create process, activate 
process, and kill process) as well as inter¬ 
process handshaking functions. 

All OPS5 programs are upwardly com¬ 
patible with the Cops environment. Inter¬ 


faces have also been written to integrate 
programs in other languages (C, Franz 
Lisp, and Fortran) to the interprocess 
communication scheme. 

Constructing blackboards. Black¬ 
boards can be constructed as shown in 
Figure 4. One program is assigned to han¬ 
dle blackboard functions. Its Working 
Memory constitutes the actual black¬ 
board. Other programs can create new 
elements directly on this blackboard by 
using the send action. They can read from 
the blackboard with the aid of ambas¬ 
sadors placed in the Production Memory 
of the blackboard program. Each am¬ 
bassador is a set of rules that describes 
what Working Memory elements are to be 
read and manipulated. All ambassadors to 
a blackboard use cycles of the associated 
Inference Engine, simplifying the locking 
schemes and serializing the access to data. 
At present, the ambassadors cannot be 
created dynamically but must be loaded 
during the initialization of the blackboard 
program. 

The Production Memory of the black¬ 
board program can also contain a moni¬ 
tor, a permanent kernel of rules to monitor 
the blackboard, handle its upkeep, and 
oversee the ambassadors. 

The Discrete Event 
Simulator 

The purpose of this simulator is to com¬ 
pute the configurational changes that will 
result from a disturbance, given the initial 
state of a power network and a set of 
device misoperations. 


Configurational changes are produced 
by the operation of breakers. The break¬ 
ers, in turn, are activated by various relays 
distributed over the power network. Ex¬ 
amples are an overcurrent relay that 
operates when the current it measures ex¬ 
ceeds a preset threshold, and a distance 
relay that operates when the impedance it 
measures falls below a preset value. The 
relays are carefully coordinated to provide 
overlapping layers of protection. If, after 
some preset delay, the breakers closest to a 
disturbance have failed to operate proper¬ 
ly, then the next closest set of breakers is 
activated, and so on. 

The simulator uses a chronicle of events 
to describe the response of a power net¬ 
work to a disturbance. This chronicle is a 
list of elements, each of which has the 
form 

( T,EV l ...EV n ) 

where EV x ...EV n are the events that oc¬ 
cur at time T. The chronicle is generated 
with the aid of rules, one example of which 
is given below. 

IF .Breaker <b> has status “closed” 
.Breaker <b> is activated by relay 
<r> 

.Relay <r> has status “timed-out” 
.Relay <r> is of type “zone-2” 

.The present reading of the simu¬ 
lator’s clock is <s> 

THEN .Modify the status of breaker < b > to 
“open” 

.Add “Breaker <b> opens on zone 
2” to the chronicle at time <s >. 

(Here <x> means “variable x.”) 

This rule states that if a relay has timed- 
out, all the breakers activated by the relay 
must be opened. 
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The discrete event simulator is written in 
OPS5 and Lisp. It currently contains 250 
rules and 24 Lisp functions. These enable 
it to model networks containing about 10 
different kinds of relays and a variety of 
models in which they can misoperate. Fur¬ 
ther details are available. 8-9 

The Concurrent 
Simulator 

The Concurrent Simulator is a small, 
rule-based program with its own black¬ 
board. Its purpose is to arrange for run¬ 
ning copies of the Discrete Event 
Simulator in parallel. This simulator takes 
about 100 times longer to run than any 
other program in the library. Often, 
studies require many independent simula¬ 
tions. To speed up such studies, the Con¬ 
current Simulator makes copies of the 
Discrete Event Simulator, seeks out the 


most lightly loaded computers, and sets 
the copies to running in them. The results 
from the copies are posted on the Simula¬ 
tion Blackboard as they come in (Figure 
1). From here, they are transferred to the 
Main Blackboard. 


The Diagnostician 

The Diagnostician is an expert system 
whose purpose is to identify the initiating 
disturbance and any misoperating devices 
responsible for an accidental change in the 
configuration of a network. 

The Diagnostician views a power system 
as a collection of buses (nodes), lines 
(devices connecting pairs of buses), break¬ 
ers, and relays. The buses and lines can be 
in two conditions—faulted or unfaulted. 
The breakers and relays can also be in two 
conditions—properly operating or misop¬ 


erating. Each breaker has two states— 
open and closed. The breakers are as¬ 
signed to protect the lines and buses in 
coordinated, multilayered hierarchies. 
When a line or bus is faulted, its first layer 
of protecting breakers is supposed to 
open. 

The Diagnostician attempts to deter¬ 
mine the condition of each device, given 
data on the initial and final configurations 
of the network. These data may contain 
errors incurred in collection. 

Humans who are expert in solving such 
problems use a two-stage process. First, 
they identify a sub-network that contains 
all the breakers reported to have changed 
state as well as all the devices protected by 
these breakers. Next, they hypothesize cir¬ 
cumstances (combinations of faults, mis- 
operations, and data errors) to account for 
the configurational change. The Diagnos¬ 
tician replicates this two-stage reasoning 
process as described below. 


Blackboard program 



Figure 4. A 

blackboard in Cops. 
Programs post 
messages on the 
blackboard by using 
the send action. They 
read messages with 
the aid of “am¬ 
bassadors.” 
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Figure 5. The image of a por¬ 
tion of the Allegheny Power 
System. Such images are con¬ 
structed from information col¬ 
lected from sensors distributed 
over the network. Errors can 
distort the image. For instance, 
though breaker H5 is shown to 
be open, it may actually be 
closed. (Closed breakers are 
denoted by unmarked square 
boxes, open breakers by square 
boxes with crosses in them.) 



Let: 

TS be the set of breakers reported as 
having opened. (TS is called the 
Transition Set.) 

MN be the set of lines protected by 
breakers in TS as well as the nodes 
at the ends of these lines. 

MN is the sub-network that must 
be examined further. 

CLj be the set of breakers protecting 
line i and not in TS. 

CN „ be the set of breakers protecting 
node n and not in TS. 

SL j be the set of breakers not protect¬ 

ing line i and in TS. 

SN „ be the set of breakers not protect¬ 
ing node n and present in TS. 

MN is searched with the aid of heuristics 

encoded in the form of rules. Two ex¬ 
amples of these rules follow. 

IF .There exists a line <1> 

,CL <)> is empty 
.SL <i> is empty 

THEN .Hypothesize a permanent fault on 
line <1>. 

IF .There exists a node < n > 

•CL <n> is [<b> j 
.Breaker <b> has a backup com¬ 
posed of the set B 
•SL <n > = B 

THEN .Hypothesize a permanent fault on 
node <n> and a failure of breaker 
<b> to open, causing a “transfer 


Paraphrased, the first rule states that if 
all breakers protecting a line are open and 
no other breakers are open, then probably 
there is a permanent fault on the line. (If 
the fault had been temporary, the breakers 
might have automatically reclosed.) The 
second rule states that if all but one of the 
breakers protecting a node have opened 
and if the backups for the one abstaining 
breaker have opened, then it is likely that 
there is a permanent fault on the line and 
the one abstaining breaker has failed to 
operate properly. 

At present, the Diagnostician can gener¬ 
ate 23 different types of hypotheses and 
rank them in terms of their likelihood. 
This is done with the aid of about 150 rules 
written in OPS5. At one stage, the Diag¬ 
nostician had more than twice as many 
rules and far fewer capabilities. 8 As is the 
case with many expert systems, we are con¬ 
tinually adding more knowledge and find¬ 
ing more efficient ways to express it. 

The user interface 

The user interface is written in OPS5 
and contains about 175 rules. It allows the 
user to examine and change the contents 
of the main blackboard. In particular, the 
user can transfer problem descriptions 
from a file of case studies to the main 
blackboard, edit these descriptions, in¬ 


voke the programs in the library in various 
combinations, intervene in the programs’ 
executions, and view any or all of the 
results. This is done with terse commands. 
Some examples, slightly modified to make 
them self-explanatory, are load case 3, 
open breaker b5; run the diagnostician 
and check the results with the discrete 
simulator. 

Results are displayed in alpha-numeric 
form. Graphic capabilities may be added 
later. 

Usage 

To illustrate how Toast may be used, 
consider an incident in which some break¬ 
ers have been reported to have suddenly 
opened (Figure 5). A number of different 
combinations of disturbances, device mis- 
operations, and data transmittal errors 
could be responsible. The Diagnostician 
can hypothesize what these might be and 
rank them in terms of their likelihoods 
(Table 1). It can also roughly explain its 
lines of reasoning. For instance, the expla¬ 
nation for the first hypothesis in Table 1 is 
When there is a fault on line HB, breakers 
H4 and H10 are backups for H5. If all 
three of these breakers have opened, then 
the backup coordination scheme has mis- 
operated. Timer HT5 (which provides 
such coordination) is the most likely 
culprit. 
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Table 2. The chronicle of events 
drawn up by the Discrete Event 
Simulator for the third hypothesis 
in Table 1. 

Time in 

second Events 

0 Fault in Line H8 

Failure on Breaker H5 
Breaker H6 opens on Zone 
1 and Zone 2 

Breaker B1 opens on Zone 
1 and Zone 2 

1 Breaker B2 opens on Zone 

1 and Zone 2 

Breaker B4 opens on Zone 
1 and Zone 2 

Breaker B5 opens on Zone 
1 and Zone 2 


2 

Breaker D54 opens on 

Zone 2 

Breaker D51 opens on 

Zone 2 

6 


9 


12 


15 


17 

Breaker H4 opens on 
backup 

Breaker HI 0 opens on 
backup 

18 


33 


122 


303 


603 

Calendar of Events 
empty-steady state 
achieved 

"Indicates relatively minor events, such 

as the initiation of a timer relay, which are 

not shown in this summary. 


Detailed examinations of network be¬ 
haviors can be made with the simulators. 
Suppose, for instance, the user would like 
to know exactly what happens to the net¬ 
work under the circumstances of the third 
hypothesis. The Discrete Event Simulator 
can produce either a complete list of events 
or a summary of the major events (Table 
2). When several simulations are re¬ 
quested, the scheduler will automatically 
arrange for them to run concurrently in 
the most lightly loaded machines. 


T he environments in which power sys¬ 
tem operators work are becoming 
more complex. New constraints are 
appearing, old constraints are tightening, 
and the number of decision variables is in¬ 
creasing. To cope with these trends, 
operators need intelligent assistants to 
help manage information and lighten their 
decision-making burdens. Such assistants 
can be divided into two types: Phase-1 
assistants for off-line uses and Phase-2 
assistants for on-line, real-time uses. Toast 
is an evolving Phase-1 assistant. 

Of the nine possible functions of an 
assistant, Toast has immediate potential in 
two—diagnosis and criticism. Its diag¬ 
nostic knowledge, though hardly com¬ 
plete, is extensive enough to be useful to 
human operators. In contrast, its abilities 
to critique proposed courses of action are 
much less developed and, as yet, consist 


only of facilities to simulate some of these 
courses of action. 

Toast has been written in Cops, a pro¬ 
gramming environment that allows for 
distributed processing and has a readily 
extensible library of both symbolic and 
numerical programs. These features should 
make the task of expanding Toast relative¬ 
ly painless. Of the many directions in 
which expansions could occur, we plan on 
adding diagnostic capabilities in the area 
of power system security. This area was 
identified in a study 8 as the most worthy 
of development. □ 
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CAM Information Systems Planner 


At TRW's Electronic Systems Group in San Diego, California, we're 
engaged in the design and development of highly sophisticated 
digital and RF systems/subsystems for tactical defense and avionics. 
We currently have an opportunity for a CAM Information Systems 


You will be responsible for defining information flo 
manufacturing workstations and defining/sizing the s' 
this information. Information will include drawings 
cations for manual assembly, machine controls for 
assembly, barcode readings for identification and 
data. Subsequent tasks will include specification ol 
system's shop floor control portion, and managemi 
development and implementation. 



facturing information systems. Previous work in a CIM or Avionics 
house is a plus, as is experience in robotics and VAX Program¬ 
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of performing systems analysis and programming. BS in Com¬ 
puter Science, Math or Engineering required. 

You must have a desire to relocate as the position will ultimately 
be located in San Diego. 

TRW offers very competitive salaries and a flexible benefits program 
that includes medical/dental/vision care coverage and a 401 (k) stock 
savings plan. Send your resume today. Tomorrow is taking shape 
at a company called TRW. Mail to: Gary Jong, TRW Avionics 
Manufacturing Facility, R2/2150, Dept. IEEEC7, One Space 
Park, Redondo Beach, CA 90278. 
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PROLOG AND KNOWLEDGE 

INFORMATION 

PROCESSING 



Doug DeGroot, Lecturer 
Monday, October 6,1986 
Florentine Room—9:00 a.m.-5:00 p.m. 

Audience: Intended for programmers, programming man¬ 
agers and software managers. 

Course Description: PROLOG will be introduced and 
evaluated. Starting with a quick introduction to logic, the 
seminar continues with a series of complex PROLOG exam¬ 
ples; Unification and resolution are explained; A simple 
PROLOG interpreter is explored to show how the control 
component of PROLOG works; A series of typical applica¬ 
tion domains of PROLOG are investigated. Upon comple¬ 
tion the student should be able to begin writing PROLOG 
programs and develop an appreciation of the language’s 
power, ease of expression and simplicity of control. 

Course Outline: 

• Fundamental Logic 

• Simple PROLOG Examples 

• Data Structures 

• Unification and Resolution 

• A Simple PROLOG Interpreter 

• PROLOG an Expert System 

• Knowledge Data Base Management 

• Control of Searching and Backtracking 

• Implementation Details 

• Performance Issues 

Doug DeGroot received a B.S. in Mathematics and Ph D. 
in Computer Science, both from the University of Texas at 
Austin. While there, he was a member of the Texas Re- 
configurable Array Computer (TRAC) project, with special 
responsibility for operating system design and machine 
performance simulations. Upon graduating in 1981, he 
joined IBM's T. J. Watson Research Center. In July of 1985 
he became Vice President of Research and Engineering at 
Quintus Computer Systems. He is Chairman of ACM’s 
SIGARCH and served as Technical Chairman of the IEEE 
1985 International Conference on Parallel Processing and 
General Chairman of the IEEE 1985 Symposium on Logic 
Programming. 


TECHNIQUES AND 
STRATEGIES FOR 
RESTRUCTURING 
SOFTWARE 

_ / 


Robert S. Arnold, Lecturer 
Monday, October 6,1986 
Gold Room—9:00 a.m.-5:00 p.m. 

Audience: This seminar is for software developers, main- 
tainers, and managers—those concerned with how software 
deterioration can be prevented and with the techniques/ 
tools for remedying it. 

Course Description: Hard-to-change software is deval¬ 
ued software. This seminar is dedicated to preserving an 
organization's software investment. This seminar will: 

• Show how software restructuring can help achieve soft¬ 
ware maintenance goals. 

• Present over 30 techniques for restructuring software, 
and how to make a wise choice among them. 

• Show how to calculate when software restructuring will 
pay, and when it won’t. 

• Show how to stop software structure from deteriorating 
in the first place. 

Course Outline: 

• The Benefits of Software Restructuring 

• Software Renewal: A Restructuring Case Study 

• Metrics for Software Structure 

• Criteria for When to Restructure Software 

• Incremental Restructuring: Software Change Without 
Software Deterioration 

• A Survey of Software Restructuring Techniques 

• Practical Issues in Applying Restructuring Techniques 

• Deciding When Software Restructuring Will Pay 

Robert S. Arnold is a member of the technical staff at the 
MITRE Corporation. He has taught professional seminars 
in software maintenance, software testing, software quality 
assurance, design techniques, C, and UNIX*. 

Dr. Arnold is Program Co-Chair for the Conference on Soft¬ 
ware Maintenance—1987 and he is also a member of the 
IEEE Working Group on a Standard for Software Quality 
Metrics. Dr. Arnold received his Ph.D. in computer science 
from the University of Maryland in 1983 and his M.S. in 
computer science from Carnegie-Mellon University in 1977 


' UNIX is a trademark of AT&T Bell Laboratories. 
















NEW PARADIGMS FOR 
SOFTWARE DEVELOPMENT 


INTERACTIVE SOFTWARE 

DEVELOPMENT 

ENVIRONMENTS 


William W. Agresti, Lecturer 
Tuesday, October 7,1986 
Gold Room—9:00 a.m.-5:00 p.m. 

Audience: Software engineers and managers who are inter¬ 
ested in the process of software development and alterna¬ 
tives to the software life-cycle model. 


Course Description: The software life-cycle “waterfall" 
model has been criticized recently as not always being a 
useful model of the development process. This tutorial 
exposes the limitations and assumptions of the life-cycle | 
model. Prototyping, operational specification, and transfor- I 
mational implementation are presented as the bases of new 
paradigms of software development that respond to criti- I 
cisms of the life-cycle model. Examples will illustrate how \ 
these three methodologies are being used today. The tuto¬ 
rial discusses an organization’s transition from the life-cycle 
to newer paradigns. The framework for a more flexible 
development process is introduced. 

Course Outline: 

• Introduction—process models of software development; 
the evolution and assumptions of the conventional life- 
cycle 

• Critiques of the Life-Cycle—its observed inadequacies 
relative to constantly shifting requirements, maintenance, 
specification/design interaction, end-user development, 
and reusability 

• Prototyping—what, when, how and why to prototype; 
industry examples; support tools; evaluating a prototype; 
discarding vs. evolving a prototype 

• Operational Specification—the operational approach; 
behavior-producing specifications; case studies 

• Transformational Implementations—current approaches; 
examples of transformational systems; expert systems 
support 

• The Flexible Development Process—a proposed new 
base model of software development; its customization 
based on process drivers. 

William W. Agresti is a senior computer scientist with 
Computer Sciences Corporation in Silver Spring, Maryland. 
His applied research and development projects support 
the Software Engineering Laboratory at NASA’s Goddard 
Space Flight Center. He is task leader on software engi¬ 
neering studies and project leader of a NASA-CSC team 
that is designing and building flight dynamics software in 
Ada*. From 1973-83 he held various faculty and adminis¬ 
trative positions at the University of Michigan-Dearborn, 
including founding Director of Computer and Information 
Sciences. Dr. Agresti received his B.S. degree from Case 
Western Reserve University, and the M.S. and Ph.D. from 
New York University. 


*ADA is a registered trademark of the U.S. Government 
(Ada Joint Program Office). 


Anthony I. Wasserman, Lecturer 
Tuesday, October 7,1986 
Florentine Room—9:00 a.m.-5:00 p.m. 

Audience: Designers of software development environ¬ 
ments, software developers, and managers of software 
development organizations. 

Course Description: This tutorial presents the state of 
the art in the use of interactive systems for software devel¬ 
opment. The seminar proceeds from general considera¬ 
tions of human factors and history of interactive systems, 
through examination of specific tools and development envi¬ 
ronments to an examination of both the short and medium 
term future of interactive development evironments. Par¬ 
ticular attention is given to the use of high performance 
workstations based on bit-mapped graphical displays, and 
to the necessary software development tools for such an 
environment. A distinction is drawn between programming 
environments and more general software development 
environments. 

Course Outline: 

• Introduction 

Methodologies and Environments 
Components of Environments 

Programming Environments vs. Software Development 
Environments 

• Software Tools 

Types of Tools 

Structured Editors for Program Development 
Debugging and Testing Aids 
Documentation Aids 
Tool Integration 
Architectures for Environments 
Tool Communication 
Open vs. Closed Architectures 
Hardware Support for Software Development 
Environments 

Programming Systems—INTERLISP 
Operating System Based Environments—UNIX 
The Software through Pictures* Environment 

• Toward Improved Development Environments 

Anthony I. Wasserman is Professor of Medical Informa¬ 
tion Science at the University of California, San Francisco, 
and a Lecturer in the Computer Science Division at the 
University of California, Berkeley. He is a founder and Pres¬ 
ident of Interactive Development Environments, Inc., of 
San Francisco. He is the principal architect of the User Soft¬ 
ware Engineering methodology for the development of 
interactive information systems. His research interests 
include programming environments and software develop¬ 
ment methodology. 


* Software through Pictures is a trademark of Interactive Develop¬ 
ment Environments, Inc. 
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SYSTEMS 

Session Chairperson: Tsun S. Chow, AT&T Bell Laboratories, 
USA 
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Yong Juang, Northwestern University and Benjamin Wah, 
University of Illinois at Urbana-Champaign, USA 
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Enhancement, M. A. Bassiouni and U. Khamare, Univer¬ 
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Inamdar, Syracuse University, USA 
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Session Chairperson: Albert Hawkes, Sargent & Lundy 
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Pamela T. Surko, AT&T Bell Laboratories, USA 
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University, USA 
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Productivity Solution, USA 
AISPE: An Advanced Industrial Software Production 
Environment; Giorgio Bruno, Paolo Spiller and Ivo Tota, 
Politecnico di Torino, ITALY 

Automating Structured Analysis; Andy Simmons and Alan 
Hecht, Cadre Technologies Inc., USA 
A Generation System for Language-Oriented Editors; Takao 
Tenma, Hideaki Tsubotani, Minoru Tanaka and Tadao 
Ichikawa; Hiroshima University, JAPAN 


Session FL-2W—Florentine Room 
DISTRIBUTED SYSTEMS 

Session Chairperson: Jie-Yong Juang, Northwestern Univer¬ 
sity, USA 

The Design of an Adaptable Distributed System; Bharat 
Bhargava and John Riedl, Purdue University, USA 
Discrete Event Simulation in a Distributed System; K. 
Venkatesh, T. Radhakrishnan and H. Li, Concordia Univer¬ 
sity, CANADA 

A Distributed Specification Model and its Prototyping; Yu 
Wand, GTE Laboratories Inc., USA 


Session GP-2W—Grant Park Room 

REASONING TECHNIQUES FOR KNOWLEDGE-BASED 

SYSTEMS 


Session Chairperson: James Ferrans, Gould Research 
Center, USA 

An Evaluation of Two New Inference Control Methods; Y. 

H. Chin and W. L. Peng, National Tsing Hua University, 
TAIWAN 

Learning Dominance Relations in Combinatorial Search 
Problems; Chee-Fen Yu and Benjamin Wah, University of 
Illinois at Urbana-Champaign, USA 

Fuzzy Reasoning Based on Lambda-LH-Resolution; Xu-Hua 
Liu, Carl K. Chang and Jing-Pha Tsai, University of Illinois at 
Chicago, USA 


3:30 p.m.-4:00 p.m. Break 


4:00 p.m.-5:30 p.m. Four Parallel Sessions 
Session GP-3W-Grant Park Room 
MEASUREMENT TOOLS 

Session Chairperson: Nicholas Marselos, AT&T, USA 
Software Quality Measurement Tools and Techniques; 
Deborah A. Cerino, Rome Air Development Center, USA 
The Effective Configuration Management Environment; 
Michael W. Evans, Paul C. Houk, Karl M. Pearson and Gary 
W. Furr, EXPERTWARE, Inc., USA 










Session Chairperson: Motoei Azuma, NEC Corporation, 
JAPAN 

Panelists: Terry Baker, IBM Corporation, USA 

Elizabeth A. Buie, Computer Science Corpora¬ 
tion, USA 

Irene Greif, MIT, USA 
TBD, NTT, JAPAN 


Session GH-3W-Great Hall 

SOFTWARE REQUIREMENTS SPECIFICATION 

Minireview: Paul C. Jorgensen, Arizona State University, USA 


THURSDAY, October 9,1986 

9:00 a.m.-10:00 a.m. Plenary Session—Gold Room 
SOFTWARE PRODUCTIVITY 

Howard Yudkin, President, Software Productivity Consortium, 
Inc., USA 

10:00 a.m.-10:30 a.m. Break 


10:30 a.m.-12:00 p.m. Four Parallel Sessions 
Session GH-4T—Great Hall 

COMPARING ALTERNATIVE SOFTWARE ESTIMATION 
MODELS AND SYSTEMS-PART II 

Session Chairperson: Howard A. Rubin, Hunter College, 
USA-ESTI MACS model 
Panelists: Barry Boehm, TRW, USA 

Larry Putnam, Quantitative Software Manage¬ 
ment, USA-SLIM model 
Robert Tausworthe, USA 

T. Capers Jones, Software Productivity Research, 
USA-SPQR model 
Alan Albrecht, USA 
Ken Zwanzig, USA 
Session GO-4T-Gold Room 
REQUIREMENTS SPECIFICATIONS 
Session Chairperson: Carl K. Chang, University of Illinois at 
Chicago, USA 

Use of Formal Requirement Specifications with EDE in a 
Software Development Environment; Michael Goedicke, 
University of Dortmund, WEST GERMANY 
Complete Specifications and the Sorcerer’s Apprentice 
Problem; Paul C. Jorgensen, Arizona State University, USA 
Requirements Clustering for Incremental Construction of 
Software Systems; P. Hsia, A. T. Yaung and S. H. Jiam, 
University of Texas at Arlington, USA 

Session WI-4T—Windsor Room 
COMMUNICATION PROTOCOLS 

Session Chairperson: Lorraine Duvall, NT Research Institute, 
USA 

Synthesis and Performance Evaluation of Error-Recoverable 
Protocols; C. V. Ramamoorthy, Y. Yaw, R. Aggarwarl, J. Song, 
University of California at Berkeley and W. T. Tsai, Univer¬ 
sity of Minnesota, USA 

FLUIDE: A Multiple Data and Control Flow Computing Orga¬ 
nization; Jacques Skubich, Institute National des Sciences 
Appliquees, FRANCE 

A New Algorithm for Fast Protocol Validation; Yoshiaki 
Kakuda, Yasushi Wakahara and Masamitsu Norigoe, 

Kokusai Denshin Denwa Company, Ltd., JAPAN 

Session FL-4T— Florentine Room 

SPECIAL PURPOSE COMPUTER SYSTEMS FOR SUPPORT¬ 
ING Al APPLICATIONS 

Minireview: Benjamin Wah, University of Illinois at Urbana- 
Champaign, USA 

12:00 p.m.-1:30 p.m. Lunch Break 


1:30 p.m.-3:00 p.m. Five Parallel Sessions 


Session Chairperson: Joseph Cavano, Rome Air Development 
Center, USA 

An Approach to Measuring Data Structure Complexity; W. 


Session FL-3W—Florentine Room 

THE IMPACT OF KNOWLEDGE-BASED TECHNOLOGY 

Session Chairperson: Carl K. Chang, University of Illinois at 
Chicago, USA 

Panelists: Don McNamara, GE Corporate Research, USA 
Kiyoh Nakamura, FUJITSU Limited, JAPAN 
Weider Yu, AT&T Bell Laboratories, USA 
R. C. T. Lee, National Tsing Hua University, 
TAIWAN 

6:00 p.m.-9:00 p.m. Conference Reception—Gold Room 


T. Tsai, M. A. Lopez, V. Rodriguez and D. Volovik, University 
of Minnesota, USA 

On Complexity Metrics Oriented for Distributed Progams 
Using Ada Tasking; S. M. Shatz, University of Illinois at Chi¬ 
cago, USA 

An Empirical Evaluation of Program Complexity Metrics; 
Joy L. Knox and Kuo-Chung Tai, North Carolina State 
University, USA 

Session GP-5T-Great Park Room 
SOFTWARE RELIABILITY 

Session Chairperson: Leslie Eaton, AT&T-IS, USA 
The Trouble with Software Reliability; G. Gordon Schul- 
meyer and Halsey Chenoweth, Westinghouse Defense & 
Electronics Center, USA 

New Directions in Software Reliability Analysis; Halsey 
Chenoweth and G. Gordon Schulmeyer, Westinghouse 
Defense & Electronics Center, USA 

Session GO-5T-Gold Room 

REALTIME REQUIREMENTS METHODS DEMONSTRATED 

Session Chairperson: Don Utter, AT&T Network Systems, USA 
Panelists: Mack Alford, General Electric Co., USA- 
Distributed Computing Design System 
Paul Clements, Naval Research Laboratories, 
USA—A7-Software Cost Reduction 
Derrick Hatley, Lier Siegler, USA—Real Time 
Structured Analysis 

John Stockenberg, SofTech, USA-SADT 
Dan Teichroew, University of Michigan, USA—A 
Structured Approach 

Stephanie White, Grumman Aerospace, USA; 
Comparison of Methods 
Session WI-5T— Windsor Room 
SUPERCOMPUTING FOR SOFTWARE APPLICATIONS 
Session Chairperson: Benjamin Wah, University of Illinois at 
Urbana-Champaign, USA 
Panelists: Faye Briggs, Rice University, USA 

Don Garra, Argonne National Laboratory, USA 
Kai Hwang, University of Southern California, USA 
Veljko Milutinovic, Purdue University, USA 
Session FL-5T—Florentine Room 
REUSABILITY OF PROGRAM CODE 
Session Chairperson: Alan Davis, BTG, Inc., USA 
SoftDA—A Reuse-Oriented Software Design System; 
Shuichiro Yamamoto and Sadahiro Isoda, Nippon Telegraph 
& Telephone, JAPAN 

CIA—The C Information Abstractor; C. V. Ramamoorthy, 
and Yih-Farn Chen, University of California at Berkeley, USA 
Support for Reusability in Genesis; C. V. Ramamoorthy, Vijay 
Garg and Atul Prakash, University of California at Berkeley, 
USA 

3:00 p.m.-3:30 p.m. Break 

3:30 p.m.-5:00 p.m. Five Parallel Sessions 

Session GH-6T-Great Hall 
SIZE METRICS 

Session Chairperson: Amrit Goel, Syracuse University, USA 
A Synthesis of Software Science Metrics and the Cyclo- 
matic Number; Bina Ramamurthy and Austin Melton, Kan¬ 
sas State University, USA 



How to Measure Software Size, and How Not To; Anany V. 
Levitin, Villanova University, USA I 

Software Development Effort Prediction Based on Function 
Points; George J. Knafl, DePaul University, and Jerome \ 
Sacks, University of Illinois at Urbana-Champaign, USA 1 

Session GP-6T—Grant Park Room 
FOURTH GENERATION LANGUAGES 

Session Chairperson: Ashok Pahwa, USA 
Panelists: Adarsh K. Arora, Gould Corporation, USA 

Neil Blumenfield, Relational Database Systems, 
Inc., USA 

Richard Hay, SIR Inc., USA 

Stewart Schuster, Relational Technology, Inc., USA 

Larry Stevens, Oracle Corporation, USA 


Session GO-6T-Gold Room 

REALTIME REQUIREMENTS METHODS DEMONSTRATED 
(continued) 

Session Chairperson: Don Utter, AT&T Network Systems, USA 
Panelists: Mack Alford, General Electric Co., USA- 
Distributed Computing Design System 
Paul Clements, Naval Research Laboratories, 
USA—A7-Software Cost Reduction 
Derrick Hatley, Lier Siegler, USA—Real Time 
Structured Analysis 

John Stockenberg, SofTech, USA—SADT 


Dan Teichroew, University of Michigan, USA-A 
Structured Approach 

Stephanie White, Grumman Aerospace, USA— 
Comparison of Methods 

Session WI-6T-Windsor Room 
TRANSITION TO WORKSTATIONS 

Minireview: Andres Rudmik, GTE Communication Systems 
Corporation, USA 

Session FL-6T— Florentine Room 
DATABASE TECHNIQUES AND APPLICATIONS 

Session Chairperson: Pramod Warty, AT&T Bell Laboratories, 
USA 

A Multimedia Document Base System for Office Support 
Work; Asao Kaneko and Yoshinori Hara, NEC Corporation, 
JAPAN 

Multidimensional Timestamp Processing; Bharat Bhargava 
and Pei-Jyun Leu, Purdue University, USA 
Evaluating Database Update Schemes: A Methodology and 
its Applications to Distributive Systems; Kathryn C. Kinsley, 
Datawise, Inc. and Charles E. Hughes, University of Central 
Florida, USA 

Deterministic Learning Automata Solutions to the Object 
Partitioning Problem; B. J. Oommen and D. C. Y. Ma, Carle- 
ton University, CANADA 


FRIDAY, October 10,1986 

9:00 a.m.-10:00 a.m. Plenary Session-Gold Room 1:30 p.m.-3:00 p.m. Four Parallel Sessions 


10:00 a.m.-10:30 a.m. Break 
10:30 a.m.-12:00 p.m. Four Parallel Sessions 
Session GH-7F—Great Hall 


METRIC EXPERIMENTS 

Session Chairperson: George Knafl, DePaul University, USA 
Software Metrics Interpretation Through Experimentation: 
Volney Rodriguez and Wei-Tek Tsai, University of Minne¬ 
sota, USA 

The Cost of Typographical Errors in Software Development; 
Frank B. Tatom, Engineering Analysis, USA 
The Relationship Between Program Complexity and Slice 
Complexity During Debugging Tasks; Herbert D. Longworth, 
Linda M. Ottenstein and Martyn R. Smith, Michigan Tech¬ 
nological University, USA 

Session GO-7F—Gold Room 
SOFTWARE MAINTENANCE 
Minireview: Wilma Osborne, NBS, USA 
Session WI-7F—Windsor Room 
VISUAL PROGRAMMING 

Session Chairperson: Takayuki Dan Kimura, Washington 
University, USA 

Panelists: Robert B. Grafton, National Science Foundation, 
USA 

Gretchen P. Brown, Computer Corporation of 
America 

Steve P. Reiss, Brown University, USA 
Ephraim P. Glinert, University of Washington, USA 
Bruce MacLennan, Naval Post Graduate School, 
USA 


Session Chairperson: Ravishankar Iyer, University of Illinois 
at Urbana-Champaign, USA 

On Testing of Functionally Equivalent Components of Fault- 
Tolerant Software; Mladen A. Vouk, Michael L. Helsabeck, 
Kuo-Chung Tai and David F. McAllister, North Carolina State 
University, USA 

Structuring Concepts for Robust Design; S. Pfleger, The 
University of Newcastle Upon Tyne, GREAT BRITAIN 
A Design Method for Recoverable Distributed Communica¬ 
tions Systems; Carl K. Chang and Tsang Ming Jiang, Univer¬ 
sity of Illinois at Chicago, USA 


12:00 p.m.-1:30 p.m. Lunch Break 


Session GH-8F—Great Hall 

AUTOMATING THE CONFIGURATION MANAGEMENT 
PROCESS 


Session Chairperson: Michael W. Evans, EXPERTWARE, Inc., 
USA 

Panelists: Steve Christiansen, Sequent Computer Systems, 
Inc., USA 

Leon Presser, Softool Corporation, USA 
Winston Royce, Lockheed Software Technical 
Center, USA 

Jack Munson, System Development Corporation, 
USA 


Session GO-8F—Gold Room 

SOFTWARE DEVELOPMENT AND MAINTENANCE 

Session Chairperson: Michael Fagan, IBM Corporation, USA 
An Evolution Model for Software Maintenance; Stephen S. 
Yau, Robin A. Nicholl and Jeffrey J.-P. Tsai, Northwestern 
University, USA 

A Survey of Program Design Languages (PDLs); Brian A. 
Nejmeh and H. E. Dunsmore, AT&T Bell Laboratories, USA 
A Review of Software Engineering Environments; Elaine 
Fedchak, NT Research Institute, USA 


Session WI-8F—Windsor Room 

VISUAL PROGRAMMING TECHNIQUES AND 

APPLICATIONS 

Session Chairperson: Robert Grafton, National Science 
Foundation, USA 

The Tinkertoy Graphical Programming Environment; Mark 

Edel, Digital Equipment Corporation, USA 

Parsing Two-Dimensional Languages; Will D. Gillett and T. 

D. Kimura, Washington University, USA 

listof: A Pragmatic Consideration of setof; Xie Zhiliang and 

Ye Gang, Shanghai Jiao Tong University, CHINA 

Session FL-8F—Florentine Room 
FAULT TOLERANT SYSTEMS 2 

Session Chairperson: Ibrahim Onyuksel, Northwestern Uni¬ 
versity, USA 

Reliability Analysis of a 3-Version Software System; Janet 
R. Dunham and Linda A. Lauterbach, Center for Digital 
Systems Research, USA 

Routing and Scheduling File Transfers in a Network with 
Time Constraints; Kazuo Sugihara, University of Hawaii at 
Manoa, USA 

Model for Execution Time Behavior of a Recovery Block; 
Ashish K. Deb and Amrit L. Goel, Syracuse University, USA 
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EXPERT SYSTEMS 


The FIS Electronics 

Troubleshooting 

System 


Frank Pipitone 

Navy Center for Applied Research in Artificial Intelligence 


FIS uses a causal 
model to update its 
beliefs about faults 
after making tests. 

It then suggests 
the next best test 
to apply. 



I n recent years, escalating maintenance 
costs for electronic equipment and the 
increasing power of artificial intelli¬ 
gence methods have led to research in the 
application of AI to electronics trouble¬ 
shooting. 1 

FIS (for Fault Isolation System), devel¬ 
oped in an ongoing research project spon¬ 
sored at the US Naval Research Labora¬ 
tory, is an expert system that directs or 
assists a technician in diagnosing faults in a 
piece of electronic equipment. FIS is a 
more highly developed version of an ear¬ 
lier system. 2 FIS has more extensive 
knowledge acquisition capabilities and ex¬ 
tensive minor improvements. It is written 
in Franz Lisp and runs on a VAX 11/780 
computer. 

Figure 1 illustrates the context in which 
FIS is intended to be used. FIS was de¬ 
signed primarily to diagnose analog sys¬ 
tems, isolating faults to the level of 
amplifiers, power supplies, and larger 
components. The methods employed in 
FIS are also applicable to the automatic 
generation of the programs that drive con¬ 
ventional automatic test equipment 
(ATE), to the real-time control of ATE, 
and to fault isolation in systems containing 
mechanical, hydraulic, optical, and other 
types of components. 

US Government work not protected by US copyright, 


First, let me describe the diagnosis prob¬ 
lem addressed by FIS. I assume that a 
knowledge engineer has documentation 
describing the function and structure of a 
specific piece of electronic gear called a 
unit under test (UUT). This documenta¬ 
tion includes schematic and block dia¬ 
grams, specified values of measurable pa¬ 
rameters at various test points, and theory 
of operation. With this documentation, 
the knowledge engineer uses FIS to create 
a computer model of the UUT. Under the 
supervision of a technician, FIS later uses 
the model to recommend tests to make and 
analyzes the test results until faulty 
replaceable modules are identified. 

The following are the principal goals of 
the FIS project: 

• enable FIS to minimize knowledge- 
acquisition difficulty by equipping it 
with a library of descriptions of com¬ 
monly occurring modules and mod¬ 
ule properties to aid the knowledge 
engineer in producing a concise 
description of each UUT’s connec¬ 
tivity and the function of each UUT’s 
modules (replacement components); 

• enable FIS to compute accurately the 
probability that a fault hypothesis is 
correct after one or more tests have 

COMPUTER 














been made on a UUT during a diag¬ 
nosis session; and 

• enable FIS to recommend to the 
technician the next test to make for 
maximum information gain and min¬ 
imum costs in setup changes and 
measurements. 

The principal novelties in FIS are the 
ability to reason qualitatively from a func¬ 
tional model of a complex UUT, without 
numerical simulation; an efficient knowl¬ 
edge-acquisition capability; and a prob- 
abalistic reasoning method specialized for 
device troubleshooting. The basic ap¬ 
proach to diagnosis is that of following 
local causal rules to obtain dynamically all 
possible causes of various abnormal test 
results. The system does not assume that 
there is only a single fault in the UUT. 
Also, global, empirical symptom/cause 
associations, such as “frequency high at 
terminal? implies module3 or module4 
bad,” are not used in the current im¬ 
plementation of FIS, although such 
“shallow-model” rules will probably be 
integrated in the future, since in many ap¬ 
plications, some empirically obtained 
symptom/cause relations are available 
and yield improved accuracy and savings 
in computation time. In FIS the modeling 
might be regarded as “shallow” for the in¬ 
dividual modules, but “deep” for the en¬ 
tire UUT. 

Much previous related research deals 
only with digital circuitry. 3-4 Most work 
on reasoning about analog devices is 
restricted to simple components because 


of the demands of performing detailed cir¬ 
cuit analysis. 5 " 7 One work 8 that treats a 
complex analog system (a radio receiver) 
requires considerable knowledge-acquisi¬ 
tion effort. Another 9 uses only a shallow 
(global symptom/cause) model. Systems 
that have general analog/digital applic¬ 
ability 10 ' 11 use only topological (connec¬ 
tivity plus directionality) knowledge about 
the UUT and therefore are forced to sus¬ 
pect all modules upstream from a failed 
test. Also, without functional modeling, 
such systems cannot handle passed tests 
well because they cannot know to what ex¬ 
tent each module upstream of a given 
passed test can be certified as good. 


System overview 

FIS is organized as depicted in Figure 2. 
The upper left-hand box (UUT descrip¬ 
tion) represents the knowledge acquired to 
describe a particular UUT type. (See the 
section on “UUT-specific knowledge,” 
below.) It contains such information as 
relative a priori probabilities of failure of 
the modules, setup and test costs, connec¬ 
tivity and function descriptions, and a 
graphics description, which is used for 
displaying a block diagram of the UUT. A 
principal concern of this unit is to 
minimize knowledge-acquisition labor. 



Figure 1. The en¬ 
vironment in which 
FIS operates. 



July 1986 


Figure 2. Overall 
FIS architecture. 
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FIS has both a library 
of causal models for 
commonly occurring 
module types and a 
library of causal 
models describing 
commonly occurring 
properties of modules. 


The upper right-hand box ( General elec¬ 
tronics knowledge) represents two kinds 
of general (UUT-independent) electronics 
knowledge: a library of “causal” models 
of generic modules that are likely to occur 
in more than one UUT, and a library of 
properties of modules. A.property consists 
of a partial causal model of a module. (See 
the sections on “General electronics 
knowledge” and “Knowledge acquisi¬ 
tion,” below.) The “general electronics 
knowledge” depicted in Figure 2 is to be 
referred to whenever possible when the 
editor is being used for the purpose of 
knowledge acquisition. The editor can 
also be used to add, delete, or modify 
generic modules or properties. 

After its completion, the UUT descrip¬ 
tion is processed by the knowledge com¬ 
piler. This produces a file containing the 
compiled UUT knowledge. The purpose 
of the compilation is simply to transform 
knowledge from a form suitable for 
editing to a form suitable for efficient 
diagnostic computation. 

The diagnostic reasoning system in¬ 
teracts during the diagnosis session with 
the compiled knowledge and with the cur¬ 
rent beliefs about UUT faults (see the sec¬ 
tion on “Processing of a test result,” 
below) to perform the following tasks: 

• find the best test to perform next; 

• update the UUT beliefs after a test is 
made; and 

• respond to a technician’s query re¬ 
garding the probability that a fault 
hypothesis is correct, the merit of a 
test, the UUT model, or the belief 
state of FIS. 


Knowledge and its 
acquisition in FIS 

As mentioned above, both general and 
UUT-specific knowledge are used in FIS. 
The general knowledge facilitates the ac¬ 
quisition of UUT-specific knowledge 
about a new UUT. 

UUT-specific knowledge. The knowl¬ 
edge required to describe a specific UUT 
type includes the following: 

(a) a graphics description, which is 
used for display of a block diagram 
of the UUT; 

(b) a list of module (component) names; 

(c) causal rules for each module; 

(d) a connectivity description; 

(e) module replacement costs; 

(f) the relative a priori module-fault 
probabilities; 

(g) costs of accessing various terminals 
as test points; 

(h) costs of testing various measurable 
parameters; 

(i) costs of setup changes; and 

0) specified parameter-value ranges 
under setup states. 

The graphics description (item (a), 
above) is generated automatically by FIS 
from the connectivity description (item 
(d)) and consists of a block diagram with 
the modules labeled by their names and 
current fault probabilities. The user can 
edit this diagram to optimize its ap¬ 
pearance. 

The most interesting UUT-specific 
knowledge is of type (c) above. It consists 
of causal rules that describe the relation¬ 
ships among measurable (in principle) pa¬ 
rameters of the various terminals of each 
module. These rules are intended to 
describe the behavior of each module in its 
context. Thus, where loading and other ef¬ 
fects of Kirchoff’s laws affect behavior, 
these are assumed to be taken into ac¬ 
count. FIS is not restricted to unidirec¬ 
tional modules with fixed I/O voltage 
behavior. For the common case in which 
module behavior is independent of con¬ 
text, the library’s module descriptions, 
when available, can be invoked without 
modification. These rules found in the 
library contain both information about 
the correct behavior of UUT modules and 
about fault modes of modules, as dis¬ 


cussed below. The rules are of the follow¬ 
ing forms: 

(1) Given precondition, parameterl 
abnormalityl at terminall always 
causes parameter2 abnormality2 at 
terminal. 

(2) Given precondition, parameterl 
abnormalityl at terminall some¬ 
times causes parameter2 abnor¬ 
mal^ at terminal. 

(3) Given precondition, faulty module- 
name sometimes causes parameterl 
abnormalityl at terminall. 

Here, a precondition is a prescription of 
values or ranges of some parameter^) at 
some terminal(s). An abnormality is 
assigned one of the qualitative values 
“high” or “low,” as described in the sec¬ 
tion on “Processing of a test result,” 
below. For example, a rule of form (1) is 
“Given that 4 < dc voltage < 6 at ter¬ 
minal t7, dc voltage high at t3 always 
causes the frequency to be low at t4.” 
This might describe the way a voltage- 
controlled oscillator propagates a voltage 
error, given that its power supply voltage is 
in spec. In the case of a module (such as a 
summing junction) with two inputs, both 
affecting the same output parameter, a 
problem can arise. Suppose two of the 
rules are “input 1 dc high sometimes 
causes output dc high” and “input2 dc 
high sometimes causes output dc high.” 
Then if “output dc high” is suspected, 
both inputs are to be suspected of being 
high. However, one might be very high 
and the other slightly low, and the latter 
would be missed. However, if such a case 
were to occur, the system would find a 
fault leading to the high input, and the en¬ 
suing repair might even cure the slightly 
low input. Otherwise, a second diagnostic 
pass could search for it. Each causal rule is 
associated before compilation with the 
module immediately connected to the ter¬ 
minals mentioned in the rule, and after 
compilation each rule is associated with 
the terminals themselves. This facilitates 
the following of causal paths during 
diagnosis. 

Rules of types (1) and (2) represent the 
correct behavior of a module in context in 
the form of relationships among measur¬ 
able quantities at its terminals. Rule type 
(1) is used for the occasional case when one 
waveform abnormality very nearly always 
gives rise to a second; for example, if a fre- 
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(b) 


Figure 3. Conventional drawing of 
a connection (a); a model of an FIS 
connection (b). 


quency is wrong at an amplifier’s input, it 
is almost sure to be wrong at the output. 

Rule type (3) represents knowledge 
about how a given module can fail. Note 
that even if there were no such fault-model 
knowledge available, all conceivable rules 
of type (3) could be included by default 
and still result in a viable diagnosis system. 
That is, one could assume that any abnor¬ 
mality at a terminal could have been 
caused by the failure of any directly con¬ 
nected module. This would lead to some¬ 
what larger “ambiguity sets” than the use 
of a more specific set of type (3) rules. (An 
ambiguity set is a set within which at least 
one faulty module must lie.) However, 
most of the diagnostic power of FIS comes 
from rules of types (1) and (2), since it is 
largely by chaining them that FIS deter¬ 
mines what portion of the UUT affects a 
given measurement. When in doubt about 
the inclusion of any rule, the user must in¬ 
clude it, else he or she risks missing some 
faults. 

The connectivity knowledge (item (d) 
above) is given in terms of triples (module- 
terminal 1, UUT-terminal, module-termi¬ 
nal) in which a module terminal is 
designated by a pair (module-name 
module-terminal-name). This notation 
enables one to write causal rules (item (c) 
relating terminals of a module without 
having to consider the connectivity, which 


is useful in referring to generic component 
models, which are described in the section 
on “Knowledge acquisition,” below. Also 
note that in the connectivity description, 
there are always two modules connected to 
one UUT-terminal. This is because metal 
conductors are modeled as modules them¬ 
selves to capture their open-circuit fault 
behavior. Thus, three module-terminals 
connected together in a “Y” become three 
UUT-terminals connecting six module- 
terminals, as shown in Figure 3. After 
compilation, the connectivity knowledge 
is represented implicitly by the causal 
rules, which then refer to terminals by 
their UUT-terminal names, not their 
module-terminal names. 

Item (e) is used as a basis for recom¬ 
mending replacement to the technician 
when replacement of a module would min¬ 
imize the expected total cost of testing and 
replacement. These costs are manifested 
primarily in time and in risk of equipment 
damage, but can be put on a common scale 
by converting them into monetary units. 

Ideally, item (f) is obtained from 
statistics of actual failures of each module 
in the current UUT type. If these are 
unavailable, failure rates for the most 
specific generic class to which a module 
belongs and for which statistics are avail¬ 
able should be used; equal probabilities 
should be assumed only as the last resort. 


Items (g) through (i) can be obtained by 
someone familiar with the UUT and with 
the test equipment that will be used on it. 
As with item (f), one can use equal costs 
for (g), (h), and (i) if statistical informa¬ 
tion is unavailable. The price paid for 
assuming equal costs is less efficient but 
nearly equally accurate diagnosis. 

Specification knowledge (item (j) is of 
the form (setup-name terminal parameter 
minimum maximum). Thus, (setupl4 t7 
RMS-voltage 4.5 5.5) specifies that the 
RMS voltage at terminal t7 must lie be¬ 
tween 4.5 and 5.5 volts or the UUT will be 
considered faulty. 

General electronics knowledge. As 

mentioned in the “System overview” sec¬ 
tion (above), FIS has both a library of 
causal models for commonly occurring 
module types and a library of causal 
models describing commonly occurring 
properties of modules. This generic 
knowledge can be referred to during the 
acquisition of a new UUT description in 
lieu of making a complete explicit descrip¬ 
tion. (For example, one can specify that a 
certain module of a UUT has the highpass 
property at one of its terminals and that it 
has the dc-amplifier property with respect 
to two terminals identified as “input” and 
“output.”) This causes the addition or 
deletion of various causal rules. (For ex- 
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The updating of beliefs 
about faults is the 
most important 
capability of FIS. 


ample, the highpass property forbids rules 
asserting the dependence of the named ter¬ 
minal’s dc value on the other terminals.) 
Individual rules can then be edited to 
achieve the rule set correctly describing the 
user’s conception of each module’s quali¬ 
tative behavior. 

Knowledge acquisition. The description 
of a new UUT is developed by a user with 
the aid of the editor, which is shown in 
Figure 2. It is expected that it will be possi¬ 
ble in the future to replace this function of 
the user at least partially with a CAD/ 
CAM database describing the UUT. For 
the most part, the 10 types of UUT- 
specific knowledge described above in the 
section of that name are acquired in a 
direct manner from the user. Item (c) (the 
caused rules of the modules) is the excep¬ 
tion. Here the user needs to transfer to the 
computer his understanding of each 
module’s behavior. For a typical UUT, 
this requires a large number of causal 
rules. Therefore, concise description is im¬ 
portant. For this reason, the editor allows 
the user four means of specifying causal 
rules for a module: 

(1) Individual rules can be entered or 
deleted by the user. 

(2) Several causal rules can be entered at 
once by expressing them in a compact 
form, for example, “The dc voltage at all 
terminals of module3 sometimes causes 
the failure of any parameter at terminal6” 
(English paraphrase). 

(3) A complete rule set for a generic 
module can be obtained from the generic- 
module library by specifying the UUT- 
specific module name, the generic module 
name, and the associations between UUT 
module terminal names and generic mod¬ 
ule terminal names. 


(4) The current rule set for a module of 
the UUT can be modified by naming prop¬ 
erties from the property library and giving 
the associations between UUT module ter¬ 
minal names and property terminal 
names. This leads to both additions and 
deletions of rules. 

Item (2) above enables the user to take 
advantage of various patterns in the rule 
set of a module. The example given causes 
the generation of all combinations (the 
outer product) of the given causes and the 
given effects. The outer product is useful 
for a complex module for which any ab¬ 
normality at one terminal can under some 
circumstances cause any abnormality at 
some second terminal, or for a complex 
module of which the user has an in¬ 
complete understanding. Another exam¬ 
ple is “All abnormalities at terminal of 
module3 sometimes cause the failure of 
the same parameter at terminal6” (English 
paraphrase). This yields a one-to-one cor¬ 
respondence between causes and effects. 
Various other compact notations are used. 
The editor expands these immediately to 
yield individual rules that can be further 
edited, if desired, by the user. 

Every rule for each UUT module carries 
a label of “mandatory” or “forbidden” 
for use during editing. After compilation, 
only the mandatory ones survive and the 
label is dropped. The reason for this 
feature is evident from item (4). Rules ob¬ 
tained by invoking a property can be of 
either the mandatory or forbidden type, 
whereas all rules of categories (1), (2), and 
(3) are mandatory. Thus, when a new rule 
is obtained by any of the four methods, if 
it is mandatory and not present in the 
UUT module rule set, it will be added. If it 
is mandatory but already present and 
marked ‘ ‘mandatory” in the UUT module 
rule set, nothing will be changed. If it is 
mandatory and present but marked “for¬ 
bidden” in the UUT module rule set, then 
the user will be called upon to resolve the 
conflict. The case of dealing with a “for¬ 
bidden” new rule is handled exactly sym¬ 
metrically. (That is, a forbidden new rule 
will be deleted unless it is marked “man¬ 
datory” in the UUT module rule set, in 
which case the user will be called upon to 
resolve the conflict. Thus, when there is a 
conflict, the user resolves it, and when 
there is not, the new mandatory rule is 
“unioned” into the UUT module rule set. 


Processing of a test 
result 

The updating of beliefs about faults 
after a test is the most important capability 
of FIS. Poor selection of tests can delay 
the diagnosis, but inaccurate use of their 
results can cause erroneous diagnosis. The 
tool employed by FIS is essentially a pro¬ 
duction system in which the rules are dis¬ 
tributed throughout the topology of the 
UUT and are used for forward and back¬ 
ward deduction about faults. In addition 
to making these deductions, they are used 
to find the set of modules to which back¬ 
ward chaining leads, which is to say, the 
ambiguity set. 

When a technician makes a test on the 
UUT, he reports the result to FIS as a four¬ 
tuple (setup, test point, parameter mea¬ 
sured, and measured value). FIS processes 
this result along with the compiled causal 
model (described above in the section on 
“Knowledge and its acquisition in FIS”) 
and the current beliefs, and produces as 
output updated beliefs. The beliefs consist 
of five types of data and represent what 
FIS currently knows about the state of the 
UUT: 

• Qualitative value set. This is defined 
for each combination of UUT setup, elec¬ 
trical terminal, and measurable parameter 
at that terminal. It is a subset of a set such 
as [lo ok hi] and represents which of these 
three mutually exclusive qualitative values 
is still feasible. Here “lo” means that the 
parameter is below spec, “ok” means that 
it is in spec, and “hi” means that it is 
above spec. These three are useful because 
they were judged to occur frequently and 
to allow causal rules that lead to small am¬ 
biguity sets. FIS can use arbitrarily defined 
qualitative values. For example, [ok, bad] 
is a useful set for binary signals. FIS can¬ 
not deal with intermittent faults. A test is 
made at most once. 

• Quantitative value. This is the numer¬ 
ical or symbolic measured value of a pa¬ 
rameter (see paragraph immediately pre¬ 
ceding), if known. 

• The set of current ambiguity sets. 
(That is, the sets of modules each of which 
is believed to contain at least one faulty 
module.) This accrues at most one new 
ambiguity set per test. 

• The current UUT setup. This is 
reported by the technician along with his 
last test result. 
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• Certification factors. These are mul¬ 
tiplied by the various a priori failure rates 
a, of the modules when FIS is calculating 
fault probabilities. (See “Calculation of 
fault probabilities,” below.) They are ini¬ 
tially “1.0,” indicating no evidence from 
tests that module i is good. Complete cer¬ 
tification is indicated by “0.0.” 

In processing a test result, FIS first up¬ 
dates the setup belief (see the fourth item 
in the list above) to match the setup re¬ 
ported with the test. Failed and passed 
tests are processed differently. FIS first up¬ 
dates the quantitative value corresponding 
to the setup, terminal, and parameter in¬ 
volved in the test. It then looks up the cor¬ 
responding specification (part of the com¬ 
piled UUT knowledge). If there is no such 
specification, no action is taken. 

If the specification is violated, the quan¬ 
titative value of the parameter measured is 
categorized by a qualitative value such as 
“lo” or “hi” and the corresponding quali¬ 
tative value set is updated by deleting from 
it all but that qualitative value. Then the 
causal rules associated with the terminal 
tested are obtained. For those “always” 
rules (see the “Knowledge Acquisition” 
section, above) whose preconditions are, 
by a special routine, estimated to be true at 
the time and consistent with their specified 
values under the current setup, the left- 
hand sides of these rules are matched 
against the failed-test result. If the test 
result matches the left-hand side of any 
“always” rule, forward chaining is carried 
out to termination and the deduced quali¬ 
tative values are recorded. Now, for all 
rules (“always” or “sometimes” types) 
whose preconditions are estimated at the 
time to be true and consistent with their 
specified values under the current setup, 
the right-hand sides are matched against 
the failed-test result. The left-hand sides of 
the matching rules now represent possible 
causes of the failed test. Those that are not 
already known to be “ok” are now 
matched recursively against rules until the 
set of all culpable modules is found. This 
set is appended to the set of ambiguity sets. 
Finding ambiguity sets is the most impor¬ 
tant use of the causal rules. The simple net¬ 
work of Figure 4 illustrates the small size 
of ambiguity sets computed with FIS. 
(Note, for example, that if a test shows the 
dc voltage to be high at T6, only the 
highpass filter can be the cause.) The 
reader can readily see how the ambiguity 


sets were found by “mentally chaining” 
through the given rules from right to left 
from each test result. 

In the case of a passed test (qualitative 
value “ok”) FIS first chains backwards 
through the “always” rules, recording the 
deductions as deletions of “high” or 
“low” from qualitative value sets. Next, 
for each module on which the test de¬ 
pends, FIS notes how many of the abnor¬ 
malities the module can cause (via a 
module fault) at its terminals lie on the 
causal path to the “low” or “high” (or 
otherwise abnormal) outcomes of the test. 
From this the new certification factor for 
that module is computed. For example, if 
a module has 10 rules of type (3) (see the 
section on “Knowledge Acquisition,” 
above) and four of the rules have right- 


hand sides on the causal path to the pres¬ 
ent and any previously passed tests, then 
the certification factor for the module is 
1 - 4/10 = .6. This rough approxima¬ 
tion is used because the a priori statistics 
for the various modes of failure of a given 
module are seldom available. 

The five types of belief information 
described in this section and the a priori 
module failure probabilities include all the 
important information about the possible 
faults in the UUT at a given time. How¬ 
ever, this information is most useful both 
to a technician and to the routine that 
computes the next best test if it is con¬ 
verted into the form of probabilities that 
fault hypotheses are correct, as described 
below. 



Rules fired in propagation of the test results given above: 


(T5 freq high) sometimes causes (T6 freq high) 

(T4 freq high) sometimes causes (T5 freq high) 

(T3 freq high) sometimes causes (T4 freq high) 

(T2 freq high) sometimes causes (T3 freq high) 

M3 sometimes causes (T3 freq high) .^3 nol dividing 
(T1 freq high) sometimes causes (T2 freq high) ' 

Ml sometimes causes (T1 freq high) ;M1 has high frequency 

(T5 dc low) sometimes causes (T6 dc low) 

M6 sometimes causes (T6 dc low) ;M6 open, M7 pulls low 

M7 sometimes causes (T6 dc low) ;M7 input grounded 

M5 sometimes causes (T5 dc low) ;M5 output has offset 

M5 sometimes causes (T5 dc high) ;M5 output has offset 

(T5 dc high) sometimes causes (T6 dc high) 


Figure 4. Simple examples of the propagation of a test result. 


July 1986 


73 













































Calculation of fault 
probabilities 

In problem domains, such as medical 
diagnosis, that are complex and for which 
deep models relating structure and func¬ 
tion are incomplete, it is is often impossi¬ 
ble to do evidential reasoning in a precise 
manner, since the relevant joint statistics 
of symptoms and causes are unavailable. 
Therefore, approximation methods have 
been found useful, such as those in 
Mycin 12 and Prospector 13 and in the 
Dempster-Shafer formalism. 14 (Mycin is 
an expert system used in medical diag¬ 
nosis; Prospector is an expert system used 
in mineral exploration; and the Dempster- 
Shafer formalism is a more recent general 
technique for evidential reasoning.) 

However, in the domain of diagnosis of 
human-engineered systems constructed 
from discrete modules, it is possible to use 
more precise probabilistic methods ex¬ 
ploiting the regularities of this domain. 
One regularity is that the information 
gleaned from a symptom can often be 
described as an “ambiguity set,” a set 
within which at least one faulty module 
must lie. Another is that the assumption 
that faults occur independently of one 
another with their own a priori probabil¬ 
ities is often an acceptable approximation. 

A fault hypothesis is defined here as a 
Boolean combination of assertions that in¬ 
dividual modules are good or faulty. For 
example, x x &x 2 &xr 3 is the hypothesis 
that modules 1 and 3 are bad and module 2 
is good. FIS contains a program that com¬ 
putes the probability of the correctness of 
a fault hypothesis in light of the test results 
to date. It is assumed that the individual 
module-fault propositions Xj are statisti¬ 
cally independent of each other with 
relative a priori probabilities a,, so that 
OjOj is the relative a priori probability of 
Xj &Xj, for example. We are thus ignoring 
the case of one component failing first and 
stressing a second component so that it 
fails also. This will cause some error in 
probability calculations, which will affect 
primarily the selection of tests and there¬ 
fore the cost (in time, money, and so on) 
of diagnosis, rather than its accuracy of 
diagnosis. Barring this coupling, we can 
view double faults as independent events, 
the second of which occurs by chance in 


the time between the occurrence of the 
first and the time of testing. 

For clarity, I will first describe how the 
program processes failed test results, and 
then I will treat passed tests. As described 
in “Processing of a test result” (above), 
each failed test gives rise to an ambiguity 
set containing all modules that could have 
caused that abnormal measurement. The 
set of these ambiguity sets corresponds to 
a Boolean conjunctive normal form ex¬ 
pression in the module fault propositions 
Xj', at least one member of the first am¬ 
biguity set is faulty and at least one 
member of the second ambiguity set is 
faulty, and so on. Let T denote this expres¬ 
sion and H denote an arbitrary Boolean 
function of the Xj and their complements, 
describing a hypothesis whose current 
probability is desired. From Baye’s Rule 
the current probability of H is given by 


P(H\T) = 


P(H&T) 

P(T) 


( 1 ) 


where P(B) is the a priori probability of the 
proposition B, that is, the a priori prob¬ 
ability that the failure state of the UUT is 
consistent with B. 

The problem is now reduced to that of 
computing P(B) for an arbitrary Boolean 
function of the literals Xj. The strategy is 
to manipulate B so that all terms of con¬ 
junctions are statistically independent 
(that is, they involve no common *,) and 
all terms of disjunctions are non-overlap¬ 
ping (that is, mutually exclusive). FIS then 
replaces the Xj with the corresponding a 
priori module-fault probabilities a, and 
the three Boolean operations with arith¬ 
metic operations by using the following 
three laws from probability theory: 

(A) If P(X) = p then P(X) = 1-p 

(B) If P(X) = p and P(Y) = q, then 
P(XvY) = p + q iff X & Y = 0 

(C) If P(X = p, P(Y) = q and X and Y 
are statistically independent, then 
P(X&Y) = pxq 

Tests that are passed are treated by the 
following method. As described in “Pro¬ 
cessing of a test result” (above), after each 
passed test, a new certification factor is 
computed for each module representing 
approximately what fraction of the mod¬ 
ule’s a priori fault probability remains. 


The a priori failure rate a, is simply 
replaced with 



prior to the use of a, as explained in the 
above paragraph. 

An efficient algorithm for performing 
the computation of equation (1) as out¬ 
lined above has been developed. I will give 
a concise trace of the algorithm’s behavior 
on an example problem. Suppose the cur¬ 
rent ambiguity sets are [m 2 , m 3 , m 4 ], 
[m 4 , m 5 , m 6 ], and [m 6 , m 7 J and the 
hypothesis is x 7 . These sets overlap in¬ 
terestingly (at least two faults are present) 
and make a good illustration. I define the 
shorthand notation P(B) = 1 - P(B), and 
Xj is denoted by i. Then the numerator of 
the right side of equation (1) becomes 


1. P(H&T) = P[(2v3v4)&(4v5v6)& 
(6v7)&7] 

2. = P[(2v3v4)&(4v5v6)&7] 

; Boolean absorption 

3. = P[(2&3&4)v(4&5&6)v7] 

;DeMorgan’s law 

4. = P[(2&3&4)v(4&5&6)v7] 

_ ;law _A,above 

5. = P[(2&3&4&(5v6)&7)v 
(4&5&6&7)v7] 

;disj unction overlap removal 

6. =1 - P(2&3&4&(5v6)&7) - 
P(4&5&6&7) — P(7) 

;law_B 

7. =_1 - P(2)P(3)P(4)P(5v6)P(7) - 
P(4)P(5)P(6)P(7) - P(7) 

;law C_ 

8. = 1 - P(2)P(3)P(4)P(5v6)P(7) - 
P(4)P(5)P(6)P(7)-P(7) 

;law A 

9. P(5v6) becomes P(5&6) 

;DeMorgan’s law 

10. P(H&T)_= 1 -__ 

P(2)P(3)P(4)(P(5)P(6))P(7) - 
P(4)P(5)P(6)P(7) — P(7) 

The P(i) are simply the a,. The denomi¬ 
nator of the right side of equation (1) is 
treated similarly. 

The above method is used after each test 
to compute the fault probabilities of the 
individual modules. It can also be invoked 
by the user to compute the probability of 
any fault hypothesis, even one including 
some fault states inconsistent with T. 
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Selection of best test 

The problem of finding the “best” test 
to make next in troubleshooting is analo¬ 
gous to that of playing a game against an 
opponent who responds randomly. The 
test result is the opponent’s move and the 
test selection is the user’s move. The user’s 
object is to minimize the cost of finding 
the faults. Think of the opponent as con¬ 
founding the user’s efforts by giving test 
results that sometimes further the user’s 
goal and sometimes don’t. Applying a 
miniaverage algorithm to the “game 
tree” 10 yields an optimal solution but is 
infeasible for large branching factors. In 
FIS, selecting a test involves choosing 
three things: setup, testpoint, and parame¬ 
ter measured. Thus, the number of tests 
can be large: one per specification given. 
At the next level of the game tree, there can 
be several test results: for example, the 
three qualitative values “low,” “high,” 
and “ok.” FIS heuristically screens the 
set of possible tests and applies a one- 
level miniaverage computation to the re¬ 
maining screened tests. That is, it finds 
the screened test that minimizes a 
weighted average of a suitable evaluation 
function over the three possible test 
results. The present version of FIS 
screens the tests by simply exhaustively 
computing the initial (opening move) 
evaluation function values at compila¬ 
tion time and then taking the best n of 
these as the screened candidate tests dur¬ 
ing diagnosis. Better screening heuristics 
are currently being investigated. 

The average is weighted by estimates of 
the probabilities of the test results. The 
probability of a high or low result is com¬ 
puted by finding the ambiguity set for that 
result and noting what fraction /,• of the 
rules of type (3) fired for each module 
rrij. Then the test result probability is 

i - no -fiPi). 

The evaluation function is the sum of the 
cost of making the necessary setup 
changes and the cost of making the mea¬ 
surement minus a measure of the informa¬ 
tion gained in making that test and obtain¬ 
ing that result. This evaluation function 
can also be queried by the technician to 
aid his decision of when to terminate 
diagnosis. 


The information gain mentioned above 
can be expressed as the change in the 
following information expression (the 
negative of the entropy of the system): 

E PitoSPi (2) 


Here p , is the current probability of the ith 
fault hypothesis and n is the number of 
modules in the UUT. Expression (2) is not 
in a suitable form for efficient computa¬ 
tion because its complexity increases ex¬ 
ponentially with the number n of modules. 
For only 20 modules, 2 20 (or 1048576) 
terms would need to be computed. FIS 
computes this quantity more efficiently by 
automatic algebraic simplification of ex¬ 
pression (2), after it expresses the Pj in 
terms of the a priori fault probabilities «, 
by using the methods described in the sec¬ 
tion on “Calculation of fault probabil¬ 
ities” (above). 

W e who designed the system have 
been testing and debugging FIS 
on small, primarily analog cir¬ 
cuits, including some taken from avionics 
communications equipment, to assess its 
performance and practicality and to gene¬ 
rate ideas for improvements. We chose cir¬ 
cuits (such as amplifiers, analog multiplex¬ 
ers, and voltage-controlled oscillators) 
having approximately 10 modules. 

Scaling FIS to larger UUTs. The com¬ 
putational complexity of the propagation 
of test results appears to be approximately 
linear in the number of terminals in the 
UUT, since during the finding of an am¬ 
biguity set or the propagation of deduc¬ 
tions through “always-rules” the number 
of rules invoked at each terminal depends 
only on the complexity of the immediately 
connected modules, not on the size of the 
UUT, and each terminal is visited at most 
once for each parameter. The complexity 
of the best-test selection is less clear, but it 
appears to be a polynomial function of the 
number of modules in the UUT. 

Even with relatively small UUTs, FIS 
shows the power of its qualitative model¬ 
ing of components in the correctness and 
small size of the ambiguity sets resulting 
from each test, as compared with a 
topologically-based troubleshooting sys¬ 
tem such as those described by Cantone et 
al. 10 and by Simpson and Balaban. 11 In 


the example illustrated in Figure 4, a pure¬ 
ly topological troubleshooting system 
would miss the loading problem of M7 at 
T6 and suspect all the modules upstream 
for any failed test. There is no known non- 
topological system with which we can 
directly compare FIS. 

The causal model required by FIS is 
modest in size and, in our experience, can 
be generated efficiently if one makes use 
of the four methods described in the 
“Knowledge acquisition” section of this 
article. This suggests that our approach 
will allow efficient knowledge acquisition 
and accurate diagnosis for larger UUTs. 

In addition to applying FIS to more 
complex and realistic UUTs, we are in¬ 
vestigating ways to add such new capabil¬ 
ities as 

• The use of quantitative relationships 
among the terminals of a module. 
(For example, the ratio of an ampli¬ 
fier’s output and input RMS voltage 
is a given gain.) Such relationships 
can be directly checked for violation 
if the relevant parameters have been 
measured. 

• Automatic deduction of qualitative 
causal rules from quantitative I/O 
relations describing modules or the 
subcomponents of modules. 

• Explanation capability. The most 
likely fault hypotheses often are ex¬ 
plainable without citing esoteric and 
lengthy probabilistic calculations. 
The sequence of causal-rule invoca¬ 
tions implicating the suspected faulty 
modules may be useful here. □ 
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EXPERT SYSTEMS 


Synapse: An Expert 
System for VLSI Design 


R A. Subrahmanyam 
AT&T Bell Laboratories 

\ ____ / 


Synapse provides a 
common basis for 
different levels of 
abstraction in VLSI 
chip design, avoiding 
the usual problem of 
disjointed concepts at 
each level. 


V LSI design involves mapping a 
problem specification into mask 
descriptions for circuit fabrica¬ 
tion. This typically spans at least three 
different dimensions for representing a 
problem—behavioral (or functional), 
structural (architectural), and physical 
(capturing placement and geometry)—as 
well as several levels of abstraction along 
each dimension. Functional abstractions 
include Boolean expressions, programs in 
conventional languages such as C, Lisp, 
Pascal, and Ada, as well as representation 
independent of axiomatic or equational 
specifications, such as programs in OBJ. 1 
Structural abstractions include descrip¬ 
tions at the register-transfer level, the 
switch-level, the transistor level, and so 
on. Physical abstractions capture place¬ 


ment and geometry, and include program¬ 
mable logic arrays (PLAs); symbolic 
descriptions that use logical symbols, for 
example, 0’s and 1 ’s, such as storage logic 
arrays (SLAs) 2 and path programmable 
logic arrays (PPLs) 3 ; symbolic descrip¬ 
tions using circuit elements 4 ; and mask- 
level descriptions. 

A major factor that complicates the 
design problem is that each of these 
dimensions has its own set of concepts, 
associated terminology, and tool idiosyn- 
cracies. We believe that a better approach 
would be to build a design system around a 
common pool of concepts (not necessarily 
common languages) which tie together the 
goings on at the various levels. By doing 
this, we would gain a common basis for 
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synthesis and analysis; conceptual integri¬ 
ty in VLSI design, which has been recog¬ 
nized as being crucial in software design; 
and the potential for developing a family 
of integrated tools rather than a discon¬ 
nected set of tools. 

This belief has led to the design of 
Synapse, * an expert system for supporting 
VLSI design. The primary goal of the sys¬ 
tem is to enable very high level specifica¬ 
tions of a problem (consisting of the 
desired functional and performance speci¬ 
fications) to be mapped into custom VLSI 
circuits. More generally, the system ar¬ 
chitecture supports the development of in¬ 
tegrated software-hardware systems. A 
small set of algebraic primitives is used to 
model several of the levels of abstraction 
along the dimensions involved in VLSI 
design. 5,6 Systems at all levels of abstrac¬ 
tion, and in all dimensions, are repre¬ 
sented as (algebraic) expressions. The 
translation process consists of repeatedly 
transforming expressions that represent 
system descriptions. 

Such an approach to VLSI design clear¬ 
ly represents a significant departure from 
most existing paradigms. Consequently, 
for a system based on this paradigm to be 
acceptable, it must support a gradual 
evolution of design paradigms, from the 
heuristic to the formal. The Synapse ar¬ 
chitecture accommodates this goal by 
allowing for expert agents that perform 
specialized subtasks in synthesis that may 
be heuristic or procedural in flavor, based 
on a taxonomy of the (sub)expressions 
representing system descriptions. Another 
goal of Synapse is to support human in¬ 
teraction and machine learning. 


System architecture 

Synapse’s transformations of formal 
expressions representing system descrip¬ 
tions are formal symbolic manipulations 
governed by the axioms characterizing 
models (user interfaces) at various levels of 
abstraction and the equational semantics 
of user-defined functions. In general, 
transformations either change the dimen- 


'Synapse may be loosely interpreted as a Synthesis 
Aid (Apprentice) for Parallel Systems (Environments). 
Any neurological associations are entirely to the credit 
of the reader. 



sion or the level of abstraction of an ex¬ 
pression (typically increasing the amount 
of detail), or they improve the system’s 
performance attributes. 

All transformations are formally prov¬ 
en to leave the functional behavior of the 
system unchanged. Such proofs need be 
carried out only once for each transfor¬ 
mation, when it is first added to the knowl¬ 
edge base. The proof itself is aided by the 
underlying formal manipulation system, 
and can be automatic or interactive. 

Figure 1 shows the general structure of 
the system component that supports for¬ 
mal manipulations. This consists of a set 
of inference rules that support various 
forms of simplification and reasoning, a 
set of axioms that capture the problem- 
specific properties and/or the user inter¬ 
face at a specific level of abstraction, and 
a set of strategy-guidance rules. This 
machinery is mostly independent of the 
expression’s dimension and the abstrac¬ 
tion level. 

The specification input to the system 
forms the initial expression. Any number 
of transformations may be applied to this 
expression, and all of the resulting expres¬ 
sions may be viewed as representing either 
legitimate outputs or intermediate design 
states. If a design has the desired perfor¬ 
mance characteristics, and is in the proper 


dimension, such as a mask description, it 
may then be viewed as a final output. 

Several implementations may typically 
be generated if all the applicable trans¬ 
formations are used. Therefore, strategies 
to focus the search in the space of alter¬ 
native designs are needed. The search 
strategy (that is, the rule-application strat¬ 
egy) is controlled by local cost estimates, 
weighting the axioms or expressions to 
bias their choice by a program, user in¬ 
teraction, and global optimization using 
an appropriate technique such as simu¬ 
lated annealing. 

While the main design development is 
top-down, the system supports bottom-up 
correction, where bottom-up information 
flow can modify some choices made dur¬ 
ing top-down design. However, these deci¬ 
sions affect only the performance criteria 
and architecture of the resultant designs. 
Functional correctness is always guaran¬ 
teed by construction independent of the 
development path’s specifics. 


Expression taxonomy: specialized sili¬ 
con compilers. Given the above general 
paradigm, it is sometimes advantageous to 
divide the (sub)expressions in system 
descriptions into different classes for com¬ 
putational efficiency. That is, we can have 
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specialized techniques to transform cer¬ 
tain classes of expressions: The strategy to 
deal with such subclasses of expressions is 
generally better understood, and therefore 
the expense of finding out what to do next 
can be greatly reduced. 

Examples of such specialized silicon 
compilation strategies (see Figure 2) in¬ 
clude techniques that deal with uniform 
recurrence equations, 7 synchronizer spe¬ 
cifications, 8 regular expressions, 9 and 
typical sequential programming con¬ 
structs. 10 An analogy is the use of built-in 
functions provided in programming lan¬ 
guage implementation for arithmetic 
operations and input-output operations, 
as well as microcoded support for com¬ 
piler implementation. 

Some of the advantages in adopting 
specialized techniques for transforming 
expression subclasses include the modu¬ 
larity gained by partitioning the system’s 
knowledge domain, the improved exe¬ 
cution efficiency (and potentially superior 
designs), and use of existing special- 
purpose software tools such as symbolic 
computations packages in Macsyma. 

A further variant that improves flex¬ 
ibility is to let the user perform the actual 
transformations. In this case, the user is 
primarily responsible for proving that the 
transformations are correct and for ensur¬ 
ing consistency between representations. 


The user-guided transformations may in 
turn be supported by an underlying 
methodology and an associated set of 
tools. While we have experimented with 
prototypes for several of the specialized 
silicon compilers described above, 8>1M2 
they are not yet integrated into the current 
implementation. 

System implementation environment. 

The environment chosen for Synapse’s 
implementation can be categorized into 
components that support the formal 
manipulations needed for inferencing and 
symbolic computation, design of the 
heuristic (expert) agents, general-purpose 
programming, and VLSI-specific opera¬ 
tions such as editors for schematics and 
symbolic layout. 

In the current implementation (see 
Figure 3), the formal manipulations are 
supported by a theorem-proving system 
written in Pascal and running on a VAX 
mainframe. 13 Some of the symbolic com¬ 
putation routines needed for complexity 
computations are implemented with Mac¬ 
syma. 14 The expert system components 
are written in a combination of KEE 15 
and ZetaLisp running on Symbolics Lisp 
Machines. 

Future generations of the system will 
more extensively use languages that direct¬ 
ly support equational reasoning and 


knowledge-based program construction. 
Such languages are not yet mature enough 
to support large software development. 

The VLSI-specific operations and 
graphics-support routines, such as those 
for editing schematics and symbolic lay¬ 
outs, are written in a combination of Lisp 
and C and execute on VLSI workstations, 
Lisp Machines, and VAX computers. The 
general-purpose programming environ¬ 
ment that combines these components is 
provided by a Lisp Machine. 

The system is configured as a set of 
loosely coupled (distributed) agents, that 
is, the agents execute on different ma¬ 
chines in a local network. The logical in¬ 
teractions are done via files and remote 
process invocations rather than via shared 
memory. This organization will be dis¬ 
cussed further after some more details of 
Synapse have been presented. 

Examples. The notion of algebraic 
“behavior expressions” used in describing 
concurrent systems in Synapse is intro¬ 
duced next. The input, output, and global 
synthesis strategy of Synapse are then 
discussed via examples. 

Behavior expressions: concurrent sys¬ 
tem specifications. Recall that a system at 
any level of abstraction—and any dimen¬ 
sion—is represented by an algebraic ex¬ 
pression. Such expressions represent mul¬ 
tipliers, sorters, arithmetic units, lists, 
integers, and the like; these objects are 
generally parameterized. 

For example, lists may be of bounded 
size N (a parameter instantiated by an in¬ 
teger) and made up of objects of type T (a 
parameter instantiated by any type that 
has a comparison operator defined on it). 
All such objects are obtained by applying 
functions to other objects. Constants are 
viewed as nullary functions, that is, func¬ 
tions with no arguments. 

To make things a little more concrete, 
consider a specification of a chip that sorts 
elements in a list. The chip, called Sort- 
Chip, accepts a list / at the port labeled 
“InputList” (denoted InputList—1) and 
outputs a sorted version of the list at the 
port labeled “OutputList” (denoted Out- 
putList—Sortfl)). This behavior may be 
described as 

SortChip = InputList—1- > 

OutputList—Sort(l) 

where / is an instance of a list and Sort is a 
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function defined on lists. The symbol - > 
may be read as “followed by” and in¬ 
dicates that the input is first accepted at the 
port InputList; this is followed by the out¬ 
put of the sorted list at the port Out- 
putList. If, as we would normally desire, 
the chip repeats this cycle, this behavior 
can be expressed by the recursive behavior 
expression 

SortChip = Input List-1 ~ > 
OutputList-Sort(l) - > SortChip 

More formally, / is an instance of the 
parameterized abstract data type List 
that can be defined axiomatically. 1 (The 
sidebar entitled “An automated proof of 
transformation equivalence” defines 
some of the functions used in this article.) 
The definition of the function Sort may 
take the form 

Sort(l) = if 1 = NewList then NewList else 
Add(Sort(Delete(l,Max(l))), Max(l)) 



Figure 3. Components of the support environment in Figure 2. Broken arrows denote 
loose coupling, while solid arrow denotes strong coupling. 


where NewList denotes an empty list and 
Add serves as a constructor function that 
builds up lists from elements. There is 
nothing distinguished about this particular 
definition for Sort. Any equivalent defini¬ 


tion can be assumed as the initial equa- 
tional specification because the equations 
define Sort only up to the congruence class 
induced by the entire set of equations 


defined on the type. Problem-specific 
rewrite rules can be used to transform an 
expression into an equivalent form if 
necessary. 


An automated proof of transformation equivalence 


The following is a transcript of an automated proof of the 
equivalence of two expressions using the simplification com¬ 
ponent of the expert system. Annotations are in italics. 

Axiom to be simplified 

1 (deletemax(add(l,x2)) = 
if((max(add(l,x2))= x2),l,add(deletemax(l),x2))); 

Rewriting rules (demodulators) 

2 (deletemax(l) = delete(l,max(l»); 

3 (delete(emptyList.l) = emptyList); 

4 (delete(add(l,x2),x3) = if((x2 = x3),l,add(delete(l,x3),x2))); 

5 (max(emptyList) = 0); 

6 (max(add(l,x2)) = if(gt(x2,max(l)),x2,max(l))); 

7 (gt(l,0) = TRUE); 

8 (gt(0,l) = FALSE); 

9 (if(TRUE,l,x2) = I); 

10 (if(FALSE,l,x2) = x2); 

11 (isemptyList(emptyList) = TRUE); 

12(isemptyList(add(l,x2)) = FALSE); 

Some of the available options in the inference rules are 
displayed t ilow. The y/n switches are user-controllable. 
Inference Rules 

1. Hyperresolution.y 7. Linkl-resolution.i 

2. Ur-resolution.n 8. Forward demodulation-1 

3. Paramodulation into 9. Back demodulation .i 

given clause.n 10. Factoring.i 

4. Paramodulation from ll.Unitdeletion.i 

given clause.n 12. Negative hyperresolution.. i 


5. Binary resolution .n 13. Linked UR resolution.n 

6. Unit resolution.n 14. Accept $TOLD clauses ... .n 

? go The simplification process is started 
given clause number 1 is: 

1 (deletemax(add(l ,x2)) = if((max(add(l,x2)) = x2),l, 
add(deletemax(l),x2))); new left-to-right demodulator 
given clause number 2 is: 

13 (if((l = if (gt(l ,max(x2)),l, max(x2))), x2, add(delete 
(x2,if(gt(l,max(x2)),l,max(x2))),l)) = if((if(gt(l,max(x2)),l,max(x2)) 

= I),x2,add(delete(x2,max(x2)),l))); ancestors: 1 2 6 2 6 4 

given clause number 3 is: 

14 (if((if(gt(l,max(x2)),l,max(x2))= I),x2,add(delete(x2,max(x2)),l))= 
if((if(gt(l,max(x2)),l,max(x2))= i),x2,add(delete(x2,max(x2)),l))); 
ancestors: 13 13 

new lex-dependent demodulator 
The given clause simplifies to true. 

The clause deletemax (emptyList) is now added to the set to be 
simplified. 

? add clause > deletemax(emptyList); 

? go I* Begin Simplification */ 

given clause number 1 is: 15 deletemax(emptyList); 

given clause number 2 is: 16 emptyList; ancestors: 15 2 5 3 

The clause has been simplified to emptyList. The two 

equivalences proved above complete the proof of the 

equivalence of the expressions delete(l,max(l)) and deletemax(l). 
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SORTER Unit in SORT-CHIP Knowledge Base 


Unit: SORTER in knowledge base SORT-CHIP 
Created by subra on 10-Nov-85 1:03:31 
Modified by subra on 11-Nov-85 9:23:19 
Member Of: (OBJECTS in kb CADRE) 


This is the input specification for a sort chip. 


Own slot: BEHAVIOR from SORTER 
Inheritance: OVERRIDE.VALUES 
ValueClass: (BEHAVIOR- EXPRESSIONS in kb CADRE) 
Comment: "The behavior-expression describing this object" 
Values: SORTER-BE 

Own slot: IMPLEMENTATIONS from OBJECTS 
Inheritance: OVERRIDE.VALUES 

Comment: "A set of one or more implementations of an object." 
Values: Unknown 

Own slot: PERFORMANCE-REQUIREMENTS from SORTER 
Inheritance: OVERRIDE.VALUES 
Pincount: (<=63) 

Time: (ORDER LENGTH *L) 

Area: (ORDER LENGTH *L) 

Values: Unknown 


Own slot: VALUE from SORTER-BE 
Inheritance: OVERRIDE.VALUES 
Comment: "PAS. Actual value of an instance." 

Facet Inheritance: OVERRIDE.VALUES 

Values: SORTER=[ (INPUT IN *L)][ (OUTPUT OUT (APPLY SORT (*L)))] 
SORTER 


Graph of the CADRE Know 


x' B 

‘ BOOLEANS<^-B1 VvNOR-BE 
" B2 OR-BE 

♦\'SCHEMA-STREAM-S-BE 
' INTEGERS^:"' 11 yXOR-BE 
'' l2 \lAND-BE 

□STS--L ' INV-SCHEMA-BE 


Figure 4. Behavior and performance specification. 


Technically, behavior expressions such 
as SortChip may also be viewed as in¬ 
stances of a type BehaviorExpression and 
are parameterized by the set of types used 
in expressions such as / and Sort(/) in the 
instantiation of the behavior expression. 

Synapse input. At the top level, an im¬ 
plementation may be viewed as a map 
from a behavior expression representing 
the desired functional behavior (initially 
the input to the system) and a performance 
vector (defined on this behavior expres¬ 
sion) embodying the desired performance 
characteristics to another behavior expres¬ 


sion (ultimately representing the output 
circuit) and an associated performance 
vector. 

Figure 4 shows the input specification 
for this example, as well as some other 
aspects of the internal representation. The 
names in boldface indicate objects with 
further structure. Attributes associated 
with objects are stored in their own or 
member slots. The values of the “mem¬ 
ber” slots are inherited by subclasses of a 
class of objects, whereas the values of the 
“own” slots are not inherited. 

The initial input object (denoted 
SORTER) has a behavior (SORTER-BE) 


similar to that described above. The per¬ 
formance vector is specified 
Area(SortChip) = 0(Length(l)), 
Time(SortChip) = 0(Length(l)), 
PinCount(SortChip) < 63. 
that is, it is specified that the chip area and 
response time be of the order of the length 
of the list being sorted, and the pincount 
be under 63. 

These metrics are parameterized by 
variables that occur in the behavior ex¬ 
pression for the input object and are 
couched in approximations appropriate 
for the level of abstraction at which the in¬ 
put is specified. It is also possible to specify 
concrete performance metrics such as 
Area(SortChip)<250 square mils. Such a 
specification, however, needs a much a 
greater degree of design elaboration 
before it can begin to guide the design 
strategy. For simplicity, we will for the mo¬ 
ment neglect the performance vector and 
concern ourselves only with the functional 
correctness of the circuit. 

To implement a sort chip, the system is 
confronted with the query 

THE IMPLEMENTATION OF SORTER 
IS ?IMP 

where the behavior expression for the 
sorter is as described above. The variable / 
in the behavior expression for the sorter 
must be defined to be, say, a list of 16 
elements, where the elements are in turn 
integers of length, say, eight bits each. The 
above assertion (or query) invokes the syn¬ 
thesis, ultimately causing the logical 
variable ?IMP to be bound to the syn¬ 
thesized implementations. 

More formally, / denotes an object that 
is a complete instantiation of a parame¬ 
terized data type List. Any object it is re¬ 
quired to implement in hardware must be a 
completely instantiated instance of a pa¬ 
rameterized type. 

The parameterized type List has two pa¬ 
rameters: the type T of its component 
elements and the size A/reflecting the most 
components the list can have. (The instan¬ 
tiating type for T must have a comparison 
operator defined on it.) By instantiating N 
with 16 and T with Integers [8] (integers of 
eight bits each) we obtain a complete in¬ 
stantiation of the type List. 

Partial instantiations in this example 
would be lists of length 16 (but of an 
unspecified element type), lists of type In¬ 
teger of unspecified length, lists of length 
16 with Integer components (but of un- 
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LAYOUT SI. 



Own slot: LAYOUT from INV-MODULE-12 
Inheritance: OVERRIDE.VALUES 

Comment: "PAS. Describes the symbolic layout of the module." 

Facet Inheritance: OVERRIDE. VALUES 
Values: (:LAYOUT (#<SYMBOLIC-DEFINITION 45556302>)) 

(TO-PARENT 

((CADRE AREA 99.0) (CADRE ASPECT 9.0 11.00) 

(CADRE :PORT-POSITION VSS 0 0) (CADRE:PORT-POSITION VSS 9 0) 
(CADRE :PORT-POSITION VDD 0 11) (CADRE:PORT-POSITION VDD 9 
11) (CADREPORT-POSmCN 
OUT05) 

(CADRE PORT-POSITION IN 04))) 


Figure 5. Partial Synapse output. 


specified bit width), and lists of unspeci¬ 
fied length, having components that are 
eight-bit integers. Such partial instantia¬ 
tions would yield partially instantiated ar¬ 
chitectural skeletons as outputs. 

System output. Given a fully instan¬ 
tiated behavior expression as input, along 
with (optional) performance require¬ 
ments, the system’s output is a mask 
description for a complementary metal- 
oxide semiconductor (CMOS) circuit. 
(The automatically synthesized output 
may not completely fulfill the desired per¬ 
formance goals; if it does not, interactive 
facilities let the designer attain the goals.) 
Figure 5 shows examples of the layout 
description for a part of the circuit pro¬ 
duced by Synapse’s leaf-cell expert. 16 

Global synthesis 
strategy 

The main steps in synthesis are 

• Automatically simplifying the input 
expression as far as possible with axioms 
and rewrite rules. 

• If desired, interactively transforming 
the expression describing the system to an 
equivalent expression, perhaps more ap¬ 
propriate for later steps. The proof of 
equivalence between the two expressions 
is aided by the underlying inference 
mechanisms. 

• Automatically mapping expressions 
at the functional level into an expression 
describing a system at the architectural 
level with general- or special-purpose 
transformation schemata. 

The intermediate expressions obtained 
during this mapping are simplified auto¬ 
matically using the axioms and rewrite 
rules that characterize the level of abstrac¬ 
tion. Both conventional compiler optimi¬ 
zations and technology-specific optimiza¬ 
tions fall into this class of manipulations. 
Furthermore, such expressions can also be 
interactively transformed into other 
semantically equivalent expressions. 

At the lower levels, the technology- 
dependent circuit-building paradigms can 
be axiomatically characterized, and the in¬ 
ference engine can synthesize the circuit 
behavior from available primitives. This 
process should be used judiciously, as it 
can become very compute- intensive. 


• Factoring the expression describing 
the system to obtain an architecture. Dif¬ 
ferent factorizations yield different parti¬ 
tionings of the resultant architecture. This 
partitioning is guided by the performance 
requirements and performance metrics, 
and can be affected by lower level design 
decisions. 

• Converting the complete structural 
description into a physical layout. This 
phase uses a system of cooperating agents 
that perform lower level tasks such as 
floorplanning and leaf cell layout. 17 Hints 
for the physical layout are obtained as part 
of the input from the previous phases of 
design. We expect that problematic aspects 
in the architectural design discovered at 
this level will be communicated back up to 
the architectural designer for subsequent 
automatic modification. 

Transforming expressions. An expres¬ 
sion describing a system—initially, the in¬ 
put specification—can be transformed 
into an equivalent expression at the same 
or at a lower level of abstraction. As men¬ 
tioned earlier, this is done automatically 
(by simplification or the use of trans¬ 
formation schemata) or interactively. In 
the interactive mode, the equivalence of 
the two expressions may be proved with 
the aid of the inference engine mentioned 
earlier. 

The following example illustrates a 
transformation on the initial expression 
defining the function Sort and describes 
the use of a special-purpose schema to 
generate a pipelined implementation for 
the input behavior expression. The reason 
for applying the first transformation is to 
coerce the initial expression defining Sort 


into a form appropriate for the special- 
purpose schema. When such transforma¬ 
tions are made automatically, they are 
guided by the available set of schemata 
and the performance criteria. 

Consider the subterm Delete(/,Max(/)) 
in the definition of Sort. It is possible to 
factor out the single common argument / 
and define a new function DeleteMax that 
operates on a list and deletes its largest ele¬ 
ment. Once this is done, the expression 
Sort(Delete(/,Max(/)) can be rewritten as 
Sort(DeleteMax(/)). An automatically 
obtained inductive proof of the equiva¬ 
lence of the two forms is illustrated in the 
sidebar entitled “An automated proof of 
transformation equivalence.” 

Special-purpose schemata. Transfor¬ 
mation schemata provide implementa¬ 
tions for subclasses of expressions. They 
are implemented as clusters of production 
rules in the expert system environment. 
Each transformation maps a behavior ex¬ 
pression (which is initially the input 
specification) into another behavior ex¬ 
pression (which is ultimately a description 
of the final circuit or a part thereof). 

Each transformation is associated with 
a set of attributes that characterize the per¬ 
formance metrics of the network that 
results from applying this transformation. 
These attributes guide the overall trans¬ 
formation strategy. Since the correctness 
of each schema is formally proven, the 
intermediate and final implementations 
(circuit architecture) are guaranteed to 
preserve the initially specified behavior. 
The correctness proofs are aided by the 
inference engine. 
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Unit: SCHEMA-INV-R1PPLE in Knowledge base CADRE 
Created by File-Server on 28-Oct-85 10:29:32 
Modified by subra on 30-Oct-85 13:38:13 
Member Of: SCHEMAS 


Own slot: BEHAVIOR-EXPRESSION-CLASS from SCHEMA-INV-RIPPLE 
Inheritance: OVERRIDE.VALUES 
ValueClass: BEHAVIOR-EXPRESSIONS 
Function-Variables: SCHEMA-INV-RIPPLE-FUNCTION 

Comment: 'This defines the class of behavior expressions that is handled by this schema.” 

Values: *INV-RIPPLE = [ (INPUT TN-1 *X.1) (INPUT TN-2*X2)][ 

(OUTPUT *OUT (APPLY *SCHEMA-INV-RIPPLE-FUNCTION (*X1 *X2)))] 
•INV-RIPPLE 

Own slot: FUNCTIONS-IMPLEMENTED from SCHEMA-INV-RIPPLE 
Inheritance: OVERRIDE.VALUES 
ValueClass: FUNCTIONS 
Cardinality. Min: 1 

Values: SCHEMA-INV-RIPPLE-FUNCTION 

Own slot: HARDWARE-MODULE from SCHEMA-INV-RIPPLE 
Inheritance: OVERRIDE.VALUES 
ValueClass: HARDWARE-MODULES 
Values: SCHEMA-INV-RIPPLE-TUPLE-MODULE 

Own slot: INPUT-REPRESENTATION-FUNCTION from SCHEMAS 
Inheritance: OVERRIDE.VALUES 
Lisp-Definition: (LAMBDA (X) X) 

Algebraic-Definition: IDENTITY 

Comment: “Defines the manner in which the input is encoded, i.e., the map from the ext 
ernal representation to the module to the internal representation for the module." 

Values: Unknown 


Figure 6. Part of a special-purpose schema. 


The schemata used by the system can be 
categorized into two classes: 

1. An extendable set of special-purpose 
schemata to synthesize implementations 
of specialized subclasses of function 
definitions (or behavior expressions). 

2. A fixed set of general-purpose sche¬ 
mata used as defaults when the needed 
behavior is neither available as a primitive 
nor synthesizable with the list of special- 
purpose schemata. 

Some representative components of a 
typical schema are input-behavior-expres¬ 
sion (function-definition), output-behav¬ 
ior-expression (the implementation), 
properties of the implementation, precon¬ 
ditions that must be satisfied by the input 
for application of this schema, and post¬ 
conditions that hold after application of 
the schema. 

An example representation of a special- 
purpose schema for linear pipelining is 


indicated in Figure 6. A schema of this 
form provides an implementation for a 
behavior/function definition that matches 
a certain template: the input behavior ex¬ 
pression. The output behavior expression 
of the schema describes a network im¬ 
plementation that results from applying 
this schema. 

Typically, the resulting network de¬ 
pends on the variable values instantiated 
when a schema matches an input behavior. 
The properties associated with a particular 
method of implementing the input behav¬ 
ior expression characterize various perfor¬ 
mance attributes of the schema, such as 
whether it decreases area or improves 
response time. The preconditions and 
postconditions respectively indicate the 
properties that must hold before and after 
the schema’s application. 

As mentioned earlier, the subterm 
Delete(/,Max(0 can be rewritten as 


DeleteMax(/), which is defined as 

DeleteMax(NewList) = NewList 

DeleteMax(Add(l,x)) = ifx > Max(l) 

then 1 else Add(DeleteMax(l),x) 

This form of the definition of the func¬ 
tions DeleteMax and Max matches func¬ 
tion definitions in two of the special- 
purpose schemata in the system. 5 Figure 7 
shows the resulting architectural skele¬ 
tons. Intuitively, the first implementation 
is an array of processors. Each processor 
transmits the larger of the top and left in¬ 
puts to the right, simultaneously trans¬ 
mitting the smaller input to the bottom. 
Overall, if the tuple representing the list is 
input at the top ports and the left ports are 
tied to - oo, the bottom outputs represent 
the input list with its largest element 
deleted and the rightmost output repre¬ 
sents the largest element in the list. 

The second implementation is a pipe¬ 
lined implementation for the combination 
of functions Delete and Max. It has an ac¬ 
cumulator that stores the largest element 
of the list portion so far streamed through 
the element. It outputs this element when 
the end-of-stream marker is input, signal¬ 
ing the end of the stream. In general, a 
transformation can provide an implemen¬ 
tation for two functions simultaneously, 
such as Delete and Max. 

Using a schema for function application 
and the fact that the function Sort has 
been transformed to the form 

Sort(l) = Add(Sort(DeleteMax(l)),Max(l)) 

we can now obtain several implementa¬ 
tions for Sort that use the previously de¬ 
rived networks for Max and DeleteMax. 
Figure 8 shows three networks that are 
automatically synthesizable by Synapse. 
The first is a single processing element with 
a feedback loop and a buffer. The second 
has a triangular shape and uses a tuple 
representation of lists for input and out¬ 
put. The third uses a linear representation 
of lists and cascades an appropriate num¬ 
ber of processing elements for Max and 
DeleteMax. 

Even after a design has been detailed to 
the level of Boolean primitives, the in¬ 
ference mechanism can be used in syn¬ 
thesis. This is done by using an axiomatic 
characterization of the lower level design 
paradigms to automatically synthesize 
some of the technology-dependent parts 
of the circuit. While such a technique can 
be used at other design levels in the design, 
this should be done judiciously because it 
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can become computationally expensive. 
The sidebar entitled “Inference engine for 
low-level synthesis” is an example of such 
a synthesis, where an inverter is automati¬ 
cally synthesized in terms of CMOS primi¬ 
tives (P-type and N-type transistors) by a 
refutation (theorem-proving) process. 

To use this technique, all functions are 
characterized by their I/O table (their out¬ 
puts are defined for each combination of 
the input values). Thus, an inverter is 
functionally characterized by a predicate 
OUTPUT(l,0,inv). This predicate states 
that the output value is 1 if the input is 0 
and that the output value is 0 if the input is 
1. The third parameter, inv, is merely a 
descriptive name tag used for book¬ 
keeping. 

For an w-input Boolean function, the 
predicate output will have 2" + 1 argu¬ 
ments: the first 2" will describe the out¬ 
puts corresponding to all possible input 
combinations, while the last parameter 
will capture the symbolic name of the 
function (or its manner of implementa¬ 
tion). 

General-purpose schemata. The behav¬ 
ior expressions in this article may be 
viewed as a language skeleton for describ¬ 
ing concurrent systems. The advantage of 
this approach is that it allows a simple 
algebraic (equational) characterization of 
the semantics of the underlying primitives, 
which in turn aids the formal algebra 
based tools. 

The functional expressions that param¬ 
eterize a particular behavior expression 
may be mapped into hardware by conven¬ 
tional silicon compilation techniques, as 
well as by transformation-based method¬ 
ologies. The current implementation of 
Synapse is mainly transformation-based. 
However, we have earlier experimented 
with other strategies 11 ' 10 that are briefly 
described below, since they can be used in 
the context of Synapse. 

To handle the general class of expres¬ 
sions, the basic syntactic constructs of the 
language must be translated into hardware 
descriptions. This has several correspon¬ 
dences with traditional compilation strate¬ 
gies, but allows various forms of hard- 
ware-specific optimizations that may not 
be relevant when generating programs. 

The main components of the compila¬ 
tion task include generating synchronizers 
to coordinate explicit parallelism such as 
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Figure 8. Examples of synthesized implementations for the function Sort, (a) A sequen¬ 
tial implementation of the Sort function, (b) A triangular network for the Sort function, (c) 
A linear pipelined network for the Sort function. 
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Inference engine for low-level synthesis 


Illustrated below is the use of the logical inference engine in 
low-level circuit synthesis. The implementation synthesized is 
the standard CMOS inverter implementation. It is described by 
the third argument in line 25 below. This illustrates the encap¬ 
sulation of some of the technology-dependent synthesis 
paradigms. 

The axioms describe how primitives can be hooked together. 
Axiom 1 lets a wire (x_jnput) be connected to the gate of a 
P-field-effect transistor (pfet) with its source connected to vdd 
(power). Axiom 2 lets a wire be connected to the gate of an 
N-field-effect transistor (nfet) that has its drain connected to 
ground. Axiom 3 lets two wires be connected together. 
Annotations are in italics. 

1. If OUTPUT(x1,x2,x__input) then 
OUTPUT(pd(x 1), pd(x2),pfet_vdd(x_in put)); 

2 If OUTPUT(x1 ,x2,x_!nput) then 
OUTPUT(ns(x1),ns(x2),nfet_vss(x_jnput)); 

3 If OUTPUT(x1,x2,x3) & OUTPUT(x4,x5,x6) then 
OUTPUT(orw(x1,x4),orw(x2,x5),orwire(x3,x6)); 

set of support: /* The search strategy focuses on these 
clauses'I 

4 OUTPUT(0,1,i1); /* Indicates that an input is available V 

5 - OUTPUT(1,0,x1); /* The negation of the desired function '/ 

Rewrite rules defining the behavior of pfets, nfets, and wires in 

the mode of usage 

demodulators: 

6 (pd(0) = 1); 

7 (ns(1) = 0); 

8 (orw(0,0) = 0); 

9 (orw(1,1) = 1); 


10 (orw(0,pd(1)) = 0); 

11 (orw(pd(1),0) = 0); 

12 (orw(1,ns(0)) = 1); 

13 (orw(ns(0),1) = 1); 

? go Begin synthesis 

given clause number 1 is: 4 OUTPUT(0,1,I1); 

14 OUTPUT(1,pd(1),pfet_vdd(i1)); ancestors: 4 1 6 

15 OUTPUT(ns(0),0,nfet_vss(il)); ancestors: 4 2 7 

16 OUTPUT(0,1 ,orwire(i 1 ,i 1)); ancestors: 4 3 4 9 8 
given clause number 2 is: 5 -OUTPUT(1,0,x1); 

given clause number 3 is: 14 OUTPUT(1,pd(1),pfet_vdd(i1)); 

17 OUTPUT(pd(1),pd(pd(1)),pfet_vdd(pfet_vdd(i1))); ancestors: 
14 1 

18 OUTPUT (0,ns(pd(1)), nf et_vss(pf et_vdd(i i)»; ancestors: 14 2 
7 

19 OUTPUT(orw(1,0),orw(pd(1), 1 ),orwire(pfet_vdd(i 1 ),i 1)); 
ancestors: 14 3 4 

20 OUTPUT(1,orw(pd(1),pd(1)),orwire(pfet_vdd(i1),pfet_vdd(i1))); 
ancestors: 14 3 14 9 

21 OUTPUT(orw(0,1),orw(1,pd(1)),orwire(i1,pfet_vdd(il))); 

ancestors: 14 3 4 

given clause number 4 is: 15 OUTPUT(ns(0),0,nfet_vss(il)); 

22 OUTPUT(pd(ns(0)),1,pfet_vdd(nfet_vss(i1))); ancestors: 15 1 
6 

23 OUTPUT(ns(ns(0)),ns(0),nfet_vss(nfet_vss(i1))); ancestors: 
152 

24 OUTPUT(orw(ns(0),0),orw(0,1),orwire(nfet_vss(i1),i1)); 
ancestors: 15 3 4 

25OUTPUT(1,0,orwire(nfet_vss(i1),pfet_vdd(i1))); ancestors: 15 
314 1013 

26 null; ancestors: 25 5 


concurrent access to shared resources, 
generating hardware modules that imple¬ 
ment the functional expressions (the func¬ 
tional modules and connections between 
them), and generating state machines 
(synchronous or self-timed, centralized 
or distributed) that control data transfers 
between modules and provide needed 
synchronization. 18 

In generating hardware modules for the 
functional expressions, we used variants 
of conventional compiler representations 
for program fragments, where the basic 
blocks (pieces of straight line code) are 
represented as directed acyclic graphs 
(DAGs) and the control flow between the 
various pieces of code is represented at the 
block level. This enables us to exploit 
various standard compiler optimization 
strategies and additionally use strategies 
specific to hardware generation. In par¬ 
ticular, we found it expedient to perform 
some block-level transformations to in¬ 
crease the amount of exploitable paral¬ 


lelism. Such transformations include 
merging blocks, eagerly evaluating for 
conditionals (evaluating both arms of a 
conditional statement in parallel, along 
with the predicate), and unrolling loops at 
compile time. 11 

The hardware description is expressed 
as a set of wired functional modules such 
as adders, registers, multiplexers, and 
multipliers. (The wires connecting the 
modules are called data paths.) A state 
machine controls the transfer of data be¬ 
tween the functional modules over the 
data paths. While this state machine 
tends to be centralized, it may in principle 
be distributed. Furthermore, the state 
machine and the associated logic may be 
either synchronous or asynchronous (or 
self-timed). 11 

Cost estimates control decisions about 
what trade-offs are made in allocating 
hardware resources. The nodes in the 
DAG are typically labeled by variables in 


the program. Actual hardware registers 
need not often be assigned to all such 
variables, since some of the program 
variables (those implemented as signals) 
are ephemeral. Different types of variables 
are often handled differently. For exam¬ 
ple, arrays below a certain size are im¬ 
plemented with a register file, while those 
above this threshold size might be im¬ 
plemented with random access memory 
cells. 

The nodes in the DAG representing 
computations to be performed have a par¬ 
tial order induced on them by data 
dependencies. The computations in these 
nodes are scheduled, subject to resource 
allocation constraints. 

We have so far experimented with three 
approaches to implementing data paths: 

• manual layout of the data path for 
SLA/PPL designs; 19 

• automatic (but suboptimal) PPL 
layout of the data path, followed by 


COMPUTER 
















Figure 9. An automatically generated leaf cell layout. 


compaction with a PPL-specific 
compactor 11 ; and 

• assuming a floor-planning paradigm 
where the bit slices (cells for each 
functional unit) are placed at right 
angles to the direction in which the 
primary data busses and global 
signals (such as power, ground, and 
clocks) are run. 

While the second technique yielded 
reasonable results in a few cases, we found 
the approach to be impractical on a large 
scale because of the compactor’s exponen¬ 
tial time algorithm. An ongoing imple¬ 
mentation of a floor planner that will be 
incorporated into Synapse aims for a more 
customized floor-planning strategy. 20 

Synchronizer synthesis. The controller 
in a hardware implementation is the state 
machine that controls data transfers be¬ 
tween functional modules. The data 
dependency between the operations 
needed to evaluate an expression can be in¬ 
ferred and expressed as a set of temporal 
constraints. A schedule for the operations 
can then be obtained from a model that 
satisfies these constraints. 5 ’ 8,21 ' 22 Synapse 
uses schema-based techniques in combina¬ 
tion with constraint-based optimization 
methods. 

Mapping structural descriptions. A 

group of experts in lower level tasks, such 
as floor planning and leaf cell layout, 
translate structural descriptions to 
physical layouts. 17 The structural descrip¬ 
tion is typically subjected to local technol¬ 
ogy-specific transformations, 23 which can 
be based on an algebraic model of the 
technology (such as structured logic arrays 
or CMOS). 6 A set of algebraic rules of in¬ 
ference can be used to determine the over¬ 
all geometric shape of the resulting net¬ 
works. Such information can be used, for 
example, to guide the floor-planning 
modules. 

A rule-based layout tool called Topolo- 
gizer 16 provides a leaf cell symbolic lay¬ 
out. This expert takes as input a descrip¬ 
tion of transistor connectivity and a set of 
constraints that define transistor sizing, 
external connection, area, and aspect 
ratio. What it produces is a CMOS sym¬ 
bolic layout of the cell in a form suitable 
for processing by the virtual grid layout 
system Mulga. 4 Figure 9 shows the output 


of a leaf cell layed out by Topologizer, and 
a comparable manually crafted cell. 

Expert system issues 

Salient features in the current version of 
Synapse, from an expert systems view, in¬ 
clude provisions for multiple perspectives 
on objects, consistency maintenance, 
search mechanisms, history maintenance, 
and machine learning. 

Perspectives. The Synapse architecture 
supports multiple perspectives on the ob¬ 
jects manipulated. A distinguishing 
feature stems from the desire for a 
framework that allows a gradual transi¬ 
tion from informally based design 
paradigms to formally based paradigms: 
Most objects have an algebraic representa¬ 
tion that provides an interface to the for¬ 
mal tools. This algebraic representation is 
typically an addition to other perspectives 
that are perhaps more common to VLSI- 
related tools, such as graphical perspec¬ 
tives for aiding user input, and display of 
the circuit representations appropriate to 
the abstraction level, such as architectural 
floor plans, schematics, and symbolic 
mask layouts. 

A procedural (Lisp) perspective is used 
to smoothly interface with the Lisp en¬ 
vironment, while the graphical and frame 
perspectives are inherited from KEE. 

It is obviously not necessary for an ob¬ 
ject to have all possible perspectives at all 
levels of abstraction. However, it is some¬ 


times important or convenient to have 
more than one perspective. 

Consistency maintenance. The Ac- 
tiveValues facility in KEE is used to main¬ 
tain consistency between multiple repre¬ 
sentations—this esseentially results in the 
invocation of demon procedures when¬ 
ever any of a set of related attributes is 
modified. (This is only done for some at¬ 
tributes in the current version of Synapse.) 

The underlying rerpesentation structure 
lets the history of the development of a 
design—both the hierarchical structure 
and the temporal ordering of the nodes 
—be maintained in a mechanically read¬ 
able form. This is intended to facilitate in¬ 
cremental redesign caused by alterations in 
the initial specifications. We plan to use a 
truth-maintenance mechanism in this con¬ 
text, particularly to record major decision 
points in the development sequence. 

Search mechanisms. Synapse uses both 
the forward- and backward-chaining 
mechanisms in KEE. Backward chaining 
is used for the main synthesis, where the 
query 

THE IMPLEMENTATION OF Initial- 
Specification IS 7SYNTHESIZED- 
IMPLEMENTATION 

causes a backward chaining of the syn¬ 
thesis rules in the appropriate rule classes. 
These rules in turn invoke the trans¬ 
formation schemata. Other parameters 
control options such as the number of dif¬ 
ferent solutions sought and whether the 
user should be consulted during synthesis. 
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The Synapse design is 
intended to support a 
gradual transition 
from heuristic to 
algorithmic to formal 
techniques. 


The overall search strategy is hierar¬ 
chical and uses a predictor-corrector ap¬ 
proach that tries to reconcile the top-down 
and bottom-up design paradigms. Top- 
down refinement (factoring/expansion of 
the expression representing the system) in¬ 
volves design decisions made on the basis 
of approximate, inaccurate, or sometime 
unavailable performance estimates of a 
decision’s effects on the eventual design. 

Two kinds of performance vectors are 
associated with each design option at a 
specific level of abstraction: a top-down 
performance estimate parameterized at 
the level of abstraction and a bottom-up 
estimate obtained from library primitives 
or previously elaborated designs. 

Based on complexity estimates at the ex¬ 
isting level of abstraction (and the next 
level of refinement), the most promising 
design option is pursued, unless a point is 
reached where the performance of the 
design is in conflict with the desired con¬ 
straints. When this occurs, the design is 
backed up to the first point where the most 
recent design elaboration allows a more 
accurate reevaluation of alternative 
designs. The best of these is then explored 
further. 

The complexity measures appropriate 
to the abstraction level under considera¬ 
tion are possible only if the design descrip¬ 
tion is appropriately parameterized. Thus, 
absolute values for performance criteria 
have only limited value until bottom-up 
complexity estimates are available. The 
framework we adopted supports such a 
parameterization naturally and therefore 
offers an important advantage over most 
other approaches. 

Furthermore, the performance vector is 
multidimensional, allowing the considera¬ 
tion of several relevant criteria during the 
early design stages. Currently, the design 
allows for area, response time, through¬ 
put, pin count, and topological hints to the 


floor planner. It is being augmented to in¬ 
clude other factors such as testability. 

Machine learning. Forward chaining is 
used for implementing machine learning 
techniques. Such learning techniques are 
used to discover new special-purpose 
schemata that help solve some subclasses 
of problems. 24 Furthermore, the system 
can learn by rote so all interactions with 
the user and the synthesized system results 
are permanently recorded and retrievable 
later. We are implementing these learning 
techniques in Synapse. 

Trade-offs in system design. The cur¬ 
rent version of the expert system is the 
fourth prototype. The previous imple¬ 
mentations had somewhat different (and 
nonoverlapping) focuses of interest. The 
first attempt focused on a program trans¬ 
formation system written in Interlisp to 
support the development of software/ 
hardware systems. The hardware target 
was SLAs, while the input was a subset of 
Ada. 10 ’ 18 The control unit was self-timed 
and generated automatically, while the 
data-path wiring was done manually. The 
second prototype 8 experimented with a 
temporal logic specification to generate 
synchronizers. The third prototype fo¬ 
cused on more traditional compilation 
strategies applied to hardware generation. 
The hardware target structures were gen¬ 
erated naively with path-programmable 
logic. The resulting layouts were opti¬ 
mized with a PPL layout compactor. 11 

The current effort is an attempt to syn¬ 
thesize custom CMOS implementations, 
placing the emphasis on tools and tech¬ 
niques that can guarantee rigorous cor¬ 
rectness of the resulting designs. In some 
senses, the current version of the system 
falls short of the long-term goals set for 
an implementation, mostly because the 
necessary programming language con¬ 
cepts, models, and implementations 
needed to support the overall structure of 
Synapse have not yet matured. These in¬ 
clude programming languages that sup¬ 
port parameterized data types with in¬ 
heritance and reasoning about formal 
equational (axiomatic) definitions. 

Another reason is that even if such a 
framework were available, several years of 
programming effort would be required to 
port all of the software tools we now use to 
the new environment. The pragmatic dif¬ 
ficulty in doing this has prompted the 


loosely coupled structure of the current 
system, which is aimed at aiding a grad¬ 
ual transition from informal to formal 
approaches. 

W e have presented an overview of 
Synapse, an expert system in¬ 
tended to aid in the design of 
custom VLSI circuits. 

The distinguishing features of the 
Synapse architecture, compared to related 
efforts 25 ' 31 aimed at aiding VLSI design 
include 

• a cohesive formal algebraic frame¬ 
work that supports input specifica¬ 
tions at a very high abstraction level, 
• algebra-based synthesis, verification 
and analysis techniques and tools 
across a wide spectrum of design 
tasks, 

• the use of conventional expert system 
tools and special-purpose theorem 
pro vers, 

• bottom-up feedback during design, 
and 

• accommodation of machine learning 
techniques, including rote learning. 
Synapse is a means to explore language 
and expert systems issues in VLSI design, 
and is part of a long-term research project. 
It is therefore important to realize that the 
Synapse design is intended to support a 
gradual transition from heuristic to algo¬ 
rithmic to formal techniques. Future work 
will be directed at enriching the knowledge 
base of the system and augmenting its 
learning capabilities. □ 
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Knowledge and Control 
for a Mechanical 
Design Expert System 


David C. Brown, Worcester Polytechnic Institute 
B. Chandrasekaran, Ohio State University 


An expert system 
using a hierarchical 
approach following 
the same procedures 
humans do shows 
that computers can 
do routine design 
work. 



M ost first-generation expert sys¬ 
tems have been rule-based with a 
separate inference engine. How¬ 
ever, a large unstructured collection of 
rules clearly lacks validity as a realistic 
model of design because reducing all 
knowledge to a single form does not 
recognize that there are many different 
types of knowledge used in any design 
problem-solving activity. 

Using such a collection of rules also 
does not recognize that design knowledge 
forms into clusters. Nor does it specify 
where or when this knowledge is to be ap¬ 
plied, since different clusters of knowledge 
may be applicable at different times. 
Similarly, using a single, central all¬ 
purpose inference engine ignores the 
richness of design problem-solving. Yet 
another problem is the potential for un¬ 
focused system behavior because all rules 
have equal status in the system and have 
equal potential for use. 
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Many systems structure rules into sets. 
However, these sets are based on subtasks 
rather than on types of knowledge, 1-3 and 
the problem solving is still uniform, as the 
same inference engine acts on each rule 
set. Advocates of such structuring claim 
the subtasks can be solved linearly with no 
backtracking between tasks and with only 
minimal backtracking within tasks. 

Such subtask structure tells us more 
about the nature of the domain than about 
design, since it is clear that design deci¬ 
sions of any kind can often be wrong and, 
if so, will lead to attempts to recover from 
failure. The uniform rule representation 
and the lack of knowledge-dependent 
structure does not provide clear predic¬ 
tions about an expert’s failure-recovery 
behavior. 

These problems stem mainly from a 
basic mismatch between the level of the 
tools available to build systems and the 
level of abstraction of the design task. 
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Consequently, for more complex forms of 
expert problem solving, there is a need for 
tools at the task level. Such tools must pro¬ 
vide a rich set of design-related task-level 
constructs. They should be helpful in cap¬ 
turing more structured forms of knowl¬ 
edge, and should help organize both 
knowledge and problem-solving behavior 
for more focused problem-solving. 

Generic tasks in reasoning. The 
Laboratory for AI Research at Ohio State 
is developing a framework in which in¬ 
vestigation of generic tasks in knowledge- 
based reasoning plays a fundamental 
role. 4 Appropriate families of knowledge 
structures and control regimes are con¬ 
structed for each generic task. From this 
perspective, design as a generic task calls 
on and uses distinctly different types of 
knowledge and control from, say, 
diagnosis. 

This point of view naturally leads to 
families of high-level languages for expert 
system construction. These languages let 
domain knowledge be captured much 
more lucidly by using primitives ap¬ 
propriate to the task. They also make ap¬ 
propriate classes of control behavior avail¬ 
able to the designer. For the design 
subclass we call routine design, we have 
developed DSPL, a task-level language. 
(“DSPL” stands for Design Specialists 
and Plans Language.) 

Design is a complex activity, one that ar¬ 
tificial intelligence has only relatively weak 
theories of, especially for more creative 
design activity. In routine design, the 
structure of the artifact is fixed and stan¬ 
dard methods of designing various parts 
are known. 

However, there is still a complex prob¬ 
lem-solving activity: integrating and satis¬ 
fying all the constraints of the particular 
design problem. Rough design and back¬ 
tracking occur in this design process, but 
much of the problem solving is piecing 
together the design rather than creating 
new methods. In our view, a substantial 
part of design activity in industry is of this 
type. Thus, our approach could be widely 
applied. 

We use the domain of mechanical com¬ 
ponents—air cylinders in particular—to 
motivate our research. 5 The AIR-CYL 
system described later shows how our 
routine design problem-solving approach 
can be applied. 


Other work in design. The nature of 
design has been discussed considerably 
among artificial intelligence researchers. 
The circuit design domain is one area 
where somewhat more sophisticated issues 
about the structure of knowledge and con¬ 
trol in design have been discussed, but 
even there relatively few systems consider 
design problems in ways that are not ad 
hoc. 6-9 

In the mechanical systems domain, the 
work of Simmons, Dixon, and Cohen 10 
and Mittal, Morjaria, and Dym 11 share 
our interest in producing a theory of 
design. The former authors concentrate 
on a theory of redesign, while the latter in¬ 
clude plans and active design knowledge in 
their theory, much as we do. Stefik, 12 too, 
presents an important view of design but is 
concerned with less routine design activity. 
His Constraint Posting mechanism could 
be used in an explanation of how routine 
design knowledge is produced. 

However, this design research did not 
lead to generic languages and architectures 
to support design as a problem-solving ac¬ 
tivity (which is at least partly our aim). We 
have deliberately sought a level of design 
where the complexity of knowledge and 
control can be limited, but where more 
powerful building blocks than those now 
available can be provided in return. On the 
other hand, the complexity of the design 
problems solvable by our framework is 
still higher than those solved with the rule- 
based paradigm. 

Design components. Design is a highly 
creative activity involving diverse prob¬ 
lem-solving techniques and many kinds of 
knowledge. Clearly, since we don’t know 
many of the problem-solving components 
of general design and since we poorly 
understand the components we do know 
about, a comprehensive detailed model of 
design is out of reach. 

However, there is agreement about 
many components of design activity. 
There is an element of refinement: 
Descriptions get refined into less abstract 
forms. Plans are used in recognizable 
situations. Such plans result from 
repeated use of past planning and valida¬ 
tion. Design activity often has a rough 
design phase followed by design proper. 

Design organization reflects the struc¬ 
ture or functionality of what is being 
designed. Similarly, the design representa¬ 
tion is also structured. During the design, 


various restrictions are checked at ap¬ 
propriate points. The initial conditions 
(requirements) form a starting set of 
restrictions. 

Routine design 
approach 

In routine design, the designer selects 
from previously known sets of well- 
understood design alternatives. The 
choices may be simple at each point in the 
design, but overall the task is still too com¬ 
plex to be done by merely looking in a 
design database because there are too 
many possible combinations of initial re¬ 
quirements. Simple choices do not imply 
simple designs or a simple design process. 
A significant portion of design activity is 
composed of these routine tasks. (While 
we have concentrated on routine design, 
we recognize that some design problems 
belong to a different type.) 

Architecture. We use the architecture of 
a hierarchically organized community of 
design agents called specialists. This 
hierarchy reflects the hierarchical struc¬ 
ture of the artifact being designed. We 
consider routine design to be largely a top- 
down activity. In our architecture, each 
specialist has a repertoire of design plans 
to accomplish certain design tasks at its 
level of abstraction. The specialists choose 
from plans, make some commitments, 
and direct specialists at lower abstraction 
levels to refine the design. Failures cause 
different kinds of actions, such as choos¬ 
ing alternative plans and transferring con¬ 
trol to a parent specialist. 

The upper levels of the hierarchy are 
specialists in the more general aspects of 
the component, while the lower levels deal 
with more specific subsystems or com¬ 
ponents. We use a hierarchy not because 
the design is intrinsically hierarchical but 
because people use hierarchies to manage 
complexity. The specialists chosen, their 
responsibilities, and their hierarchical 
organization will reflect the mechanical 
designer’s underlying conceptual structure 
of the problem domain. 

Agents. Several types of agents (active 
problem-solver modules) exist in the 
hierarchy’s decision-making structure. 
They include specialists, plans, steps, 
tasks, and constraints. 
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Specialists cooperate to refine the de¬ 
sign. Each specialist tries to design a major 
section of the component. To do this, a 
specialist uses a collection of plans. 

A plan is a sequence of calls to special¬ 
ists or tasks, possibly with interspersed 
constraints. A plan represents one method 
to design the section of the component 
represented by the specialist. A plan 
specifies the order of invocation of the 
various agents used by this design method. 

The most basic design agent is a step. 
Each step makes a design decision. It 
decides on a value for some attribute of the 
component. The value is stored in a design 
database. The decision depends on the 
current state of the design, taking into ac¬ 
count any constraints. For example, one 
step would decide the material for some 
subcomponent, while another would de¬ 
cide its length. 

A series of steps—possibly with inter¬ 
vening constraints—forms a task, which 
designs a logically, structurally, or func¬ 
tionally coherent section of the compo¬ 
nent (for example, a seat for a seal, or a 
hole for a bolt). 

Constraints test for particular relation¬ 
ships between two or more attributes at 
particular design stages. Constraints can 
occur nearly anywhere in the hierarchy. 
For example, a constraint might check 
that a hole for a bolt is not too small to be 
machinable in the material used. 13 

Problem approach. The top-most spe¬ 
cialist is responsible for the whole design. 
Specialists lower down in the hierarchy 
make detailed decisions. Each specialist 
can make design decisions about the parts 
and functions in its specialty. The deci¬ 
sions are made in the context of previous 
design decisions made by other specialists, 
as recorded in the database. Specialists can 
design their pieces themselves or use the 
services of other specialists below them in 
the hierarchy. 

Specialists in the hierarchy will refine 
the design independently, using their 
plans. Tasks attached to specialists pro¬ 
duce values using groups of steps, while 
constraints check the integrity of the deci¬ 
sions made. 

Every specialist has some local design 
knowledge, some of which is expressed as 
constraints. The constraints capture the 
major things that must be true of a 
specialist’s design before it can be con¬ 
sidered successfully completed. Other 


constraints, embedded in the specialist’s 
plans, check the correctness of inter¬ 
mediate design decisions and check the 
compatibility of subproblem solutions. 

Design phases. The design activity falls 
into four phases. 


Requirements phase. Initially, re¬ 
quirements are collected from the user and 
are verified both individually and collec¬ 
tively. Once the requirements are accept¬ 
able, the system attempts a rough design. 

Rough design phase. Rough design is 
poorly understood—but it serves at least 
two purposes. First, those values on which 
much of the rest of the design depends will 
be decided and checked. The actual at¬ 
tributes decided depend on the component 
and the domain, but it is likely that a value 
for higher level attributes, such as 
material, will be chosen in this phase. 

If these attributes can’t be achieved, 
there is little point going on with the rest of 
the design. This also prunes the design 
search space because once the overall char¬ 
acteristics of the design are established, the 
number of choices about how to proceed 
with the rest of the design diminishes. 

Second, as any mutually dependent at¬ 
tributes can prevent a design from pro¬ 
gressing, rough design can, as human 
designers do, pick a value for one of the 
attributes and use that as if the dependen¬ 
cies didn’t exist. 

Specialists have both design and rough- 
design plans to select from, depending on 
the current phase. Not all specialists will 
need both. Some phases could be mixed 
during problem-solving, but we have 
made the rough phase occur first, fol¬ 
lowed by the design phase. 

Design phase. Once rough design is 
complete, the design phase can proceed. 
Design starts with the topmost specialist 
and works down to the lowest levels of the 
hierarchy. A specialist begins by receiving 
a design request from its parent specialist. 
It refers to the specification database for 
relevant specifications and then selects a 
plan using these data and the current de¬ 
sign state. 14 

The specialist can fill in some of the 
design and can call its successors in plan- 
determined order with requests to refine a 
substructure’s design. The knowledge in 


the specialist assigns priorities to the plans 
and invokes alternative plans in case a later 
specialist fails. When all of a specialist’s 
plans fail, the specialist tells its parent. 

Redesign phase. If any failures occur 
during design, a redesign phase begins. If a 
redesign phase succeeds, the design phase 
continues where it left off. The system tries 
to handle all failures at the point of failure 
before admitting defeat and passing fail¬ 
ure information up the hierarchy. A step, 
for example, may be able to examine the 
failure and then produce another value to 
satisfy a failing constraint while still re¬ 
taining local integrity. This local attention 
to failure is an essential element of the sys¬ 
tem’s failure-handling behavior. 

Communication. The main means of 
communication in the system is passing in¬ 
formation and control messages between 
specialists across the connections forming 
the hierarchy. This restrains the control 
flow, and the system exhibits clear, well- 
focused problem-solving activity. 

Messages can request actions, report 
failures, ask for assistance, and make sug¬ 
gestions. This variety of messages is the 
key to handling subsystem interactions. 
One part of the emerging theory of design 
problem-solving is the form and content 
of these design-oriented messages. The 
design trace in the sidebar shows some of 
the types of messages used. 

Other agents. In addition to the spe¬ 
cialists in the hierarchy, the system may 
need other specialists outside the hierar¬ 
chy. These are specialists in somewhat 
more general activities commonly needed 
by several specialists in the hierarchy. For 
example, they may be certain kinds of 
stress calculation modules or database 
functions. 

In a more general design system, re¬ 
quests could be made to other types of 
problem-solvers. 15 A human user could 
act as a problem-solver, since requests for 
help will occur at well-defined points in the 
design. The expert system can subsequent¬ 
ly check the acceptability of the results 
provided. 

Routine design example 

In the company that cooperated with 
us, an air cylinder (intended for accurate 
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and reliable backward and forward move¬ 
ment of some component) had to be 
redesigned for every new customer. This 
was done to account for the particular 
space it had to fit in or the intended 
operating temperatures and pressures. 
The air cylinder, shown in Figure 1, has 
about 15 parts. 

The AIR-CYL design problem-solving 
system was developed with the task-level 
DSPL language, which was in turn devel¬ 
oped with the Rutgers ELisp language on a 
DECsystem-20. AIR-CYL demonstrated 
the viability of our routine design theory. 
We are now extending the theory and ex¬ 
amining the issues that arose while using 
the air cylinder as our test case. 

Conceptual structure. Before designing 
AIR-CYL, we interviewed an air cylinder 
designer, analyzed the design protocols, 
and obtained a trace of the design process 
to establish the underlying conceptual 
structure in making an air cylinder (see 
Figure 2). 

For example, the cylinder head was 
clearly treated as a separate conceptual en¬ 
tity. The spring was an essentially parallel 
activity, while the rest of the design was 
treated by the designer as the third major 
activity. Because specialists could be fairly 
easily identified and plans for each 
specialist were few and identifiable, de¬ 
signing an air cylinder appeared strongly 
to be a routine design activity. 

Design agents. In the examples that 
follow, we use a simplified form of the 
DSPL language. The task-based language 
allows expression of design agents, in¬ 
cluding specialists, and plans to carry out 
design objectives. 


A plan consists of a set of actions, some 
of which may be run in parallel. For exam¬ 
ple, in Figure 3, we show a plan with a task 
called Validate and Process Require¬ 
ments, a constraint called Head and 
Spring Compatible?, and a specialist 
called Rest. Together, these form the 
design plan. Some specialists will also have 
rough design plans. 

A task consists of the sequential use of 
steps, each of which obtains required in¬ 
formation, makes calculations, and makes 


a decision about the value of a single 
attribute. 

Figure 4 shows a step that decides the 
seat width for the piston seal. In this step, 
“Piston Seal Seat Width” is the name of a 
task, “Seal Seat Width ’ ’ is the name of the 
attribute being decided, “Increase Piston 
Thickness” is what the step will suggest if 
it cannot make a decision (redesign is not 
possible for this step), ‘ ‘Piston Thickness’ ’ 
is a previously designed attribute, and 
“Available > Seal Seat Width” is the 
name of a constraint. 


Air Cylinder Design Plan 


PLAN 
NAME 
TYPE 

USED BY Air Cylinder SPECIALIST 

USES Spring Head Rest SPECIALISTS 

QUALITY Reliable BUT Expensive 

FINAL CONSTRAINTS Design details OK? 

TO DO 

Validate and Process Requirements 
ROUGH DESIGN Air Cylinder 
PARALLEL DESIGN Spring AND Head 
TEST Head and Spring Compatible? 

DESIGN Rest 


STEP 

NAME 

Piston Seal Seat Width 

USED BY 

Piston Seal 

COMMENT Written by DCB 

ATTRIBUTE NAME Seal Seat Width 

FAILURE SUGGESTION INCREASE Piston Thickness 

REDESIGN 

NOT POSSIBLE 

TO DO 

KNOWNS 

FETCH Piston Thickness 

FETCH Piston Material 

FETCH Minimum Thickness 

OF Piston Material 

FETCH Spring Seat Depth 

DECISION 

Available IS 
(Piston Thickness 

MINUS DOUBLE Minimum Thickness) 
Seal Seat Width IS 0.156 

COMMENT Using one size only 

TEST Available > Seal Seat Width? 

STORE Seal Seat Width 
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Handling failures 

One view of failure handling considers 
all relevant knowledge to be available at 
failure time. Our view is that data and con¬ 
trol knowledge in human problem-solving 
is structured and probably incomplete, 


thus restricting the kinds of information 
available for handling failures. The struc¬ 
ture of the design problem-solving system 
(that is, specialists, plans, tasks, and steps) 
provides the context in which to structure 
failure handling. 

In our theory, all design agents detect 
their own failure, try to determine what 


went wrong, try to fix it locally, do so if 
they can, and report failure only if all at¬ 
tempts fail. Agents that have some control 
over other agents can use those agents 
when trying to correct the detected prob¬ 
lem. By using these ideas, we hope to 
establish what is essential for failure 
handling in this kind of design activity. 16 


An annotated trace of AIR-CYL 

This is a trace generated by the AIR-CYL system. It has been 
highly edited for brevity and for presentation in this format. The 
trace is of a successful design with step redesign and selection 
of alternative plans. We have omitted the reporting of the final 


***** AIR-CYL Air-cylinder Design System * 


* Requirements input 
From file DCB:AC-Requirements-Test 


* End of alterations from user 
*** Requirements Input Complete 


— Entering Specialist 
...AirCylinder... Mode = Design 


Entering Plan 

...AirCylinderDPI... Type = Design 


-Entering Task 

...CheckRequirements 


!!! Note: There are about 20 values given as requirements, in¬ 
cluding the maximum operating temperature and pressure and 
the size of the envelope in which the air-cylinder must fit. 

* Do you wish to alter the requirements? > > >????>yes 


-Entering Step 

...CheckEnvelope 

-Leaving Step 

....CheckEnvelope...Result = Success Msg 


EnvelopeLength 

EnvelopeHeight 

EnvelopeWidth 

MaxTemperature 

OperatingMedium 

OperatingPressureMax 

OperatingPressureMin 

RodLoad 

Stroke 

RodThreadType 

RodThreadLength 

RodDiameter 

Environment 

Quality 

MTBF 

AirlnletDiameter 

MountingScrewSize 

MountingHoleToHole 

MaxFaceToMountingHoles 

* Alterations from user 


— 7.83 
-1.5 

— 175 

— 250 

— Air 

— 60 

— 30 

— 1.4 

— 1.75 

— UNF24 
—1.031 

— (LNGTH 0.312 0.0 2.e-3) 

— Corrosive 

— - Reliable 


!!! Note: Here, the system continues to check requirements. 
Next, the design plan being followed specifies the use of the 
AirCylinder specialist in rough design mode. A rough design 
plan is selected and followed, leading to a successful rough 
design. The AirCylinder specialist then leaves rough design 
mode and continues in design mode. After quite a lot of deci¬ 
sion making involving subspecialists, we get to this point. 

-Entering Specialist 

...Rest... Mode = Design 

-Entering Plan 

...RestDPI... Type = Design 


--100000 
-- 0.374 

-- (LNGTH 0.19 5.e-3 5.e-3) 
(LNGTH 0.625 5.e-3 5.e-3) 
- (LNGTH 0.31 5.e-3 5.e-3) 


— Entering Specialist 

...PistonAndRod... Mode = Design 


!!! Note: At this point the system is working on the design of 
the piston and rod assembly. This is where the trouble starts. 


System name for requirement is > >>????> EnvelopeWidth 
Current value is 1.75 
New value is > > >????> 1.35 


-Entering Plan 

...PistonAndRodDPI... Type = Design 


!!! Note: We have cut down the width of the envelope without 
altering any other requirement to make the design harder. 


Entering Task 
...PistonSeal 


System name for requirement is > > >????>quit Entering Step 

...PistonSealType 
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Each kind of agent can have different 
kinds of reasons for failing. For example, 
a step finds that a decision violates some 
constraint, a task discovers that a step’s 
failure can’t be handled locally, a plan can 
fail if it’s not applicable to the situation, 
and a specialist can fail if all of its plans 
fail. 


For every kind of failure, a message giv¬ 
ing details is generated and passed back to 
the calling agent. The message includes, 
wherever possible, suggestions about what 
might be done to alleviate the problem. 
Because there are usually many kinds of 
problems that can occur, an agent will first 
look at the message to decide what went on 


below and what to do next. A Failure 
Handler attached to an agent contains the 
knowledge to make those decisions. 

For some conditions, immediate failure 
can be specified, while for others a re¬ 
design might be attempted. A redesigner is 
associated with an agent. It contains 


-Leaving Step 

....PistonSealType 
...Result = Success Msg 

-Entering Step 

...PistonSealSeatWidth 


!!! Note: The constraint test that follows will discover that 
there isn’t enough space in the piston for the seat for the seal 
that will go around the piston. Its failure produces a message 
that shows in detail how the failure occurred. Here we show 
only part of the message. 


-Entering TEST-CONSTRAINTS 

...(Available>Width) 

-Leaving TEST-CONSTRAINTS 

....(Available>Width)...Result = 

Failure “Constraint failure” 

Explanation “Seal width is greater than 
available space in piston” 

Suggest (INCREASE PistonThickness BY 1.517e-2) 
Suggest (DECREASE PistonSealSeatWidth 
BY 1.517e-2) 


III Note: The step failure handlers, which are built into the sys¬ 
tem, determine that a domain-specific failure handler will be 
able to decide what to do. Domain-specific failure handlers are 
written in DSPL by the expert or knowledge engineer. 

-Entering FailureHandler 

...PistonSealSeatWidthFH 


!!! Note: The domain-specific failure handler says to try 
redesign. 


-Entering Redesigner 

...PistonSSWRedesigner 
Step = PistonSealSeatWidth 

Suggest = (DECREASE PistonSealSeatWidth BY 1.517e-2) 

-Leaving Redesigner 

....PistonSSWRedesigner 
...Result= Success Msg 


!!! Note: The piston seal seat width redesigner was able to 
decrease the width as suggested. 


Leaving FailureHandler 
....PistonSealSeatWidthFH 
...Result = Success Msg 


!!! Note: WS leave the failure handler and return to the step. 
The redesign was successful, so the step is successful and 
acts as if no problems were encountered. 


Leaving Step 
....PistonSealSeatWidth 
...Result= Success Msg 


-Leaving Plan 

....PistonAndRodDPI 
... Result = Success Msg 

-Leaving Specialist 

....PistonAndRod...Result= Success Msg 

-Entering Specialist 

...Cap... Mode = Design 


III Note: Now we try to design the cap—and discover another 
problem. 


-Entering Plan 

...CapDPI... Type = Design 


-Entering Task 

...Caplnternal 

-Entering Step 

...Capl nternalDiameter 


III Note: The constraint tests to see if the internal diameter of 
the cap is larger than the outside diameter of the spring (one 
must fit in the other). It fails. 
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knowledge of how to change a design ac¬ 
cording to suggestions. 

The sidebar presents an edited trace of 
the AIR-CYL system in operation. It 
shows recovery from constraint failures. It 
also shows a plan failing and a new—and 
successful—plan being selected. 


Research issues 

We feel that while the idea of design 
refinement captures the essence of design 
problem-solving—at least in its relatively 
routine aspects—there are several impor¬ 


tant aspects of problem-solving and the 
use of plans that need mote research. 
DSPL is being studied and refined to make 
it more powerful, flexible, and easy to use. 
In addition, we hope to improve the inter¬ 
face with the system so others can use it. 
Eventually we expect to provide a graph- 


Entering TEST-CONSTRAINTS 
...(CaplD>SpringOD) 

Leaving TEST-CONSTRAINTS 
....(CaplD>SpringOD)...Result = 

Failure “Constraint failure" 

Explanation “Cap internal diameter 
too small for spring” 

Suggest (DECREASE SpringOD BY 9.9e-2) 

Suggest (INCREASE CapInternalDiameter BY 9.9e-2) 

-Entering FailureHandler 

...CapIDFH 


!!! Note: The domain-specific failure handler says to try 
redesign. 


.Entering Redesigner 

...CapIDRedesigner 
Step = CapInternalDiameter 
Suggest = (INCREASE CapInternalDiameter 
BY 9.9e-2) 

.Entering TEST-CONSTRAINT 

...(CaplD>SpringOD) 

.Leaving TEST-CONSTRAINT 

...,(CaplD>SpringOD) 

...Result = Success Msg 

-Leaving Redesigner 

....CapIDRedesigner 
...Result = Success Msg 


III Note: The redesign is successful. The suggested increase 
could be made, and the constraint was satisfied. 


Leaving FailureHandler 
....CapIDFH 

...Result= Success Msg 


!!! Note: The step is successful, since the failure was handled. 


-Leaving Plan 

....CapDP1...Result= Success Msg 

-Leaving Specialist 

....Cap...Result= Success Msg 


-Entering Specialist 

...Bumper... Mode = Design 

!!! Note: The bumper is being designed here. More problems 
are encountered. 


-Entering Plan 

...BumperDPI... Type = Design 

-Entering Task 

...BumperFlange 

-Entering Step 

...BumperFlangeDiameter 

III Note: The bumper flange diameter must be large enough to 
support the spring. The constraint tests this and fails. 


-.Entering TEST-CONSTRAINTS 

...(BFD> SpringOD) 

.Leaving TEST-CONSTRAINTS 

....(BFD>SpringOD) 

...Result= 

Failure “Constraint failure” 

Explanation “Bumper flange is too small for spring” 
Suggest (DECREASE SpringOD BY 2.995e-2) 
Suggest (INCREASE BumperFlangeDiameter 
BY 2.995e-2) 

.Entering FailureHandler 

...BumperFDFH 

!!! Note: The domain-specific failure handler says to try 
redesign. 


Leaving Step 
....CapInternalDiameter 
...Result = Success Msg 


Entering Redesigner 
...BumperFDRedesigner 
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ical interface to show the development of 
the design as it progresses. 

One possible way to deal with failures is 
to try to relax one or more of the re¬ 
quirements. Clearly some requirements 
can be softer than others—and asking the 
user for some relaxation may clear the way 


to a successful design. If much effort has 
been expended on a design by both ma¬ 
chine and human, this makes a lot of 
sense. 

It may be possible for the system itself to 
choose the requirements to relax, but a lot 
of special knowledge would be necessary 


to implement this. Even knowing when to 
ask for a relaxation will be difficult. This is 
a matter for future research. 

We are quite aware that there are bound 
to be other examples of routine design 
tasks that cannot naturally be brought 
under the plan refinement paradigm. Even 


, Step = BumperFlangeDiameter 

Suggest = (INCREASE BumperFlangeDiameter 
BY 2.995e-2) 

III Note: The redesigner falls because there is no knowledge 
about increasing the value of that attribute. 

.Leaving Redesigner 

....BumperFDRedesigner 
...Result = 

Failure “Redesigner action section fails” 

!!! Note: The failure handler reports failure and eventually the 
step gets told the bad news. 

-Leaving FailureHandler 

....BumperFDFH...Result = 

Failure "Redesigner action section fails” 

-Leaving Step 

....BumperFlangeDiameter 

...Result^ 

Failure "Step failure" 

!!! Note: The task passes the failure message from the step to 
its failure handler. It will determine if the task can do anything 
about the step failure. 

i -Entering FailureHandler 

...BumperFlangeFH 

!! I Note: The failure handler for the task discovers that no sug¬ 
gestions have been passed up from below. This means that no 
redesign can be considered. The failure handler fails because it 
couldn’t handle the problem. 


Leaving FailureHandler 
....BumperFlangeFH 
...Result = 

Failure “No relevant suggestions 
for task redesigner” 


!!! Note: The step failure and subsequent failing redesign at¬ 
tempt leads to a failure in the task. 

-Leaving Task 

....BumperFlange 
...Result = 

Failure “Task failure” 

!!! Note: The plan fails due to the failing task. 


-Leaving Plan 

....BumperDPI 
...Result = 

Failure “Plan failure” 

III Note: The next plan is selected since the last one failed. 


-Entering Plan 

...BumperDP2... Type = Design 

-Entering Task 

...BumperFlange2 

.Entering Step 

...BumperFlangeDiameter 

.Entering TEST-CONSTRAINTS 

...(BFDcCapID) 

!!! Note: This is the same constraint that failed in the last plan. 
This time it is OK. The step succeeds. 

.Leaving TEST-CONSTRAINTS 

....(BFDcCapID) 

...Result= Success Msg 

-Leaving Step 

....BumperFlangeDiameter 
...Result= Success Msg 


-Leaving Plan 

....BumperDP2 
...Result= Success Msg 

-Leaving Specialist 

....Bumper...Result= Success Msg 

-Leaving Plan 

....RestDP1...Result= Success Msg 

-Leaving Specialist 

....Rest...Result= Success Msg 

— Leaving Plan 

....AirCylinderDP1...Result= Success Msg 

-- Leaving Specialist 
....AirCylinder...Result= Success Msg 

*** Design attempt succeeds 

***** AIR-CYL Air-cylinder Design System **' 
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if it is true that design is a process of 
choosing plans and refining designs, our 
ability to construct expert systems for 
design is very much a function of the types 
of design knowledge we can capture and 
manipulate. 

We would like, as a result of our 
research, to be able to characterize the 
kinds of design problems for which our 
approach can create effective expert 
systems. 


M uch work remains to be done in 
building expert systems for rou¬ 
tine design activity before we 
can understand what design is and how 
best to build systems to do it. We feel that 
there is great need for tools that express 
knowledge at the task level. DSPL is an ex¬ 
ample of such a tool. We feel that our ap¬ 
proach of using a hierarchically structured 
system with plan selection captures the 
essential qualities of routine design.□ 
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knowledge 
ise that explicitly 
describes the 
different elements of 
design knowledge. A 
prototype version has 
been successfully 
tested on real design 
problems. 



D esigning an artifact is one of the 
most challenging problem-solving 
tasks performed by engineers. It is 
a task requiring both large amounts of 
domain-specific knowledge (that is, 
knowledge specific to the class of artifact 
being defined) as well as considerable 
problem-solving skill. Typically, one starts 
with a description of what function or 
functions the artifact should perform, and 
the task of “design” becomes one of com¬ 
ing up with an artifact that will function as 
intended. Knowledge plays a key role in 
carrying out this task. Experience with 
designing the same or similar artifacts 
allows an engineer to quickly solve the 
problem. Some of this experience can be 
viewed as knowledge that associates some 
of the requirements to parts of the artifact 
that carry out those requirements. Similar¬ 
ly, past experience can teach us how to 
configure independent parts of an artifact 

A version of this article first appeared in C. L. Dym 
(ed.). Applications of Knowledge-Based Systems to 
Engineering Analysis and Design, ASME, New York, 
>1985, pp. 99-116. Used with permission. 
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to achieve a desired overall behavior. In 
cases of making a “routine” design the 
problem-solving task is relatively simple: it 
is largely a process of matching the prob¬ 
lem requirements to previous attempts at 
meeting the same set of requirements. One 
might have to iterate over this process a 
few times to arrive at an acceptable design. 

A few attempts have been made to build 
expert systems for carrying out these kinds 
of “routine” design tasks. Dixon and Sim¬ 
mons 1 describe an architecture for doing 
mechanical design and illustrate it for a 
standard V-Belt drive design. Their model 
is based on the observation that in some 
routine design tasks one can perform a 
complete preliminary design, evaluate it, 
and then iterate this process if the evalu¬ 
ation is not satisfactory. This approach, 
which is essentially generate-and-test, 
would be computationally intractable on 
any but the simplest design tasks because 
even the smallest failure in a design leads 
to discarding the complete design and 
starting from scratch. Maher and Fenves 2 
describe an expert system for doing the 
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preliminary structural design of high-rise 
buildings. Their system is also based on a 
generate-and-test paradigm. Brown and 
Chandrasekaran 3 present a more power¬ 
ful model for handling these kinds of 
designs. In particular, their model ad¬ 
dresses questions about how to represent 
the knowledge about routine designs in 
terms of design plans, selecting between 
these plans, and a problem solver for 
managing the design modification pro¬ 
cess. Also see reference 4 for more recent 
projects in applying AI technology to en¬ 
gineering problems. 

Design activity becomes more complex 
when the artifact to be designed is marked¬ 
ly different from previous efforts, or the 
number of alternatives to be considered is 
very large, or the artifact is completely new 
(“creative” design). In general, these 
situations are characterized by a very large 
and complex design space. The space of 
possible designs may not even be well- 
defined in some cases. Thus any attempt to 
enumerate the possible designs and then 
test them will require a prohibitively large 
time. A more powerful problem solver is 
needed that can control the search through 
this vast space of possible designs in an ef¬ 
ficient manner. In these situations knowl¬ 
edge plays an essential role in suggesting 
highly plausible alternatives at each stage 
of the design. Knowledge obtained from 
experience or a deeper understanding of 
the domain may also help in modifying the 
design when some of the design choices 
turn out to be undesirable. In this article 
we describe a knowledge-based system 
called PRIDE (Pinch Roll transport In¬ 
teractive Design environment/Expert). 
This system is part of a longer term project 
whose goal is to develop a better under¬ 
standing of the nonroutine design tasks 
defined above. 


Knowledge-based tools 
for the design process 

Given the diversity and complexity of 
the design tasks performed by engineers, 
one needs to be explicit about the role of a 
computer-based tool (such as an expert 
system or a CAD-like tool) in the overall 
spectrum of design tasks. Typically, the 
design of an artifact proceeds in stages. 
The early stages deal with conceptual 


design, which involves decomposing a 
large problem into more tractable sub¬ 
problems, finding partial solutions to the 
requirements, trying to satisfy different 
(often conflicting) constraints and re¬ 
quirements, and modifying previous deci¬ 
sions. The later stages involve making 
more commitments about the spatial and 
geometrical properties of the system being 
designed and refining the conceptual 
design. In an earlier paper (see Morjaria et 
al. 5 ) we suggested that expert systems 
technology may be more suitable for the 
early stages of design, that is, conceptual 
design. 

Knowledge-guided search. Conceptual 
design can be thought of as knowledge- 
guided search of a large space of possible 
designs. Given the size and complexity of 
this space, engineers often look for solu¬ 
tions in an ad hoc fashion. Thus, good 
solutions may be completely missed or 
take a very long time to be found. Knowl¬ 
edge from previous designs can be very 
useful in this process by suggesting solu¬ 
tions that worked well in the past or by 
quickly rejecting ones that failed in the 
past. Expert systems may turn out to be a 
very suitable technology for collecting and 
transferring this knowledge. The tireless 
nature of computers ensures that a piece of 
knowledge, once articulated, would be 
systematically used in all future designs. 
Thus, bringing to bear large amounts of 
domain-specific knowledge may lead to 
more systematic, faster, and complete 
searches of the design space. 

Integration with analysis tools. Once a 
candidate design (partial or complete) has 
been identified, one can often perform a 
detailed analysis to determine if perfor¬ 
mance constraints and goals are being 
satisfied. However, the analysis techniques 
are not always known or accessible to an 
engineer. For example, such analysis tech¬ 
niques as finite-element methods are im¬ 
plemented as large programs that are not 
always easy to apply. Knowledge-based 
analysis tools can be built as expert design 
checkers. A step in this direction was the 
SACON 6 system, used for providing 
consultation on the use of the MARC 
package. One can go beyond providing an 
interface to some analysis package by in¬ 
tegrating design and analysis knowledge in 
the same knowledge base. A key benefit of 


this integration is that designs can be sys¬ 
tematically checked at each stage, instead 
of at the end. Furthermore, the failure of 
the evolving design in terms of some 
analyses can be used to look for ways to 
modify the design. 

Collaborative design. Another impor¬ 
tant aspect of the design activity is its com¬ 
munal nature. Real-world complex systems 
are often designed by a team of engineers. 
One aspect of the team effort is the decom¬ 
position of a complex system into smaller 
subsystems. However, the designs are not 
carried out in isolation. Often, an engineer 
who fails to have his or her artifact meet 
performance requirements negotiates with 
engineers designing interfacing modules in 
an attempt to relax the requirements. Thus 
engineers have to engage in exploring 
choices and in balancing different sets of 
constraints. 7 ’ 8 One of our research in¬ 
terests is to develop a better understanding 
of this process and provide assistance in 
carrying out this exploration. 

Community knowledge bases. Another 
aspect of the team effort is the distribution 
of expertise among the team members. For 
example, in the early knowledge acquisi¬ 
tion phase of the PRIDE project we found 
that different engineers often had spe¬ 
cialized knowledge for subtasks such as 
material selection or jam clearance. 9 
Knowledge-based systems provide an op¬ 
portunity to bring together the expertise 
from many different specialists. In effect, 
one could create a community knowledge 
base having more expertise than any single 
expert. 9-11 Clearly much work remains to 
be done before this vision can be realized. 
In our own work we have been interested 
in supporting many of these aspects of 
design activities. 


Design of paper 
handling systems inside 
copiers 

A copying or duplicating machine has 
several paper handling systems such as 
paper transports or paper feeders that 
move paper from one part of a copier to 
another. In building the prototype version 
of PRIDE, we have focused on one partic¬ 
ular kind of paper transports, namely, 
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Figure 1. A snapshot of the paper path and roll stations showing the input and output location and angles; the sizes and locations 
of the various obstructing regions to be avoided by the transport; the paper path drawn by the system; and the number and loca¬ 
tions of the roll stations, as determined by the system. More details about the paper path subproblem can be found in reference 5. 


ones that use pinch rolls to move the paper 
(as opposed to using belts, say). A paper 
transport must meet a large set of require¬ 
ments. These include geometrical prop¬ 
erties such as input (paper entrance) and 
output (paper exit) locations and angles 
(see Figure 1); paper properties, including 
size, weight, stiffness, and curl; and timing 


requirements and constraints, including 
entrance and exit speeds, and permissible 
skew. There may also be constraints on the 
tolerances of various engineering parame¬ 
ters, on cost, etc. Many other require¬ 
ments may be optionally imposed depend¬ 
ing on the interface system. 

Design of a paper transport can be 


typically decomposed into subproblems 
such as designing a smooth path between 
the input and output locations; making 
decisions on the number and location of 
pinch roll stations to be placed along this 
path; designing a “baffle” to be placed 
around the paper path to guide the paper; 
designing the sizes of various pinch rolls 
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(drivers and idlers); selecting the proper 
materials for the pinch rolls and baffle; 
making decisions about the velocity of the 
paper at different roll stations and forces 
acting on the paper; calculating the time 
needed to move the various sizes of paper; 
and calculating the various performance 
parameters and ensuring that they satisfy 
the design requirements. 

Typically it takes a trained engineer 
many weeks to completely design a paper 
transport. One reason is the sheer diversity 
of the task—it involves making decisions 
about geometry, spatial layout, timing, 
forces, jam clearance, etc. Often no single 
engineer knows enough to make all the 
design choices and analyses and needs to 
collaborate with other specialists. The 
same transport has to be able to handle 
different sizes and weights of paper— 
often presenting conflicting constraints. 
For example, if the lengths (or widths) of 
the different sizes of paper are far apart, 
then the constraint on the maximum 
separation of neighboring roll stations for 
the smallest paper conflicts with the con¬ 
straint on not having more than two sta¬ 
tions guiding the paper for the longer 
papers. The design of the paper path is 
complicated by the presence of obstruc¬ 
tions that have to be avoided and strict re¬ 
quirements on the smoothness, continuity, 
and manufacturability of the baffle, 
which takes the shape of the paper path. 5 
There are tight constraints related to 
buckling and stubbing of the paper that af¬ 
fect the design of the baffle, the pinch 
rolls, the paper path, and the velocities. 
The subproblem of making decisions on 
the number and location of roll stations to 
be placed along the paper path to guide the 
paper is again a constraint-driven problem 
with a large search space. 8 

This problem not only presented us with 
many of the standard criteria 12,13 for 
selecting a problem domain but also af¬ 
forded us an opportunity to advance the 
state of the art of knowledge-based and 
automated design techniques. For exam¬ 
ple, the knowledge for designing paper 
handling systems is distributed among 
many different experts, providing us with 
an opportunity to explore community 
knowledge base issues. Moreover, there 
were many analysis techniques that were 
not being adequately used by engineers to 
check their designs. This sometimes led to 
performance problems that were dis¬ 


covered only at the prototype stage or even 
later. Thus, this was an opportunity to ex¬ 
periment with bringing analysis knowl¬ 
edge closer to the design knowledge and 
study if doing so would lead to better 
designs. Also, while there was broad 
agreement among the designers about the 
overall process of designing a paper han¬ 
dling system, it was clear that a large body 
of knowledge would need to be harnessed 
in support of a problem solver that could 
effectively search a large underconstrained 
space of possible designs. In short, the task 
selected incorporated the right mixture of 
technical and economic aspects to make it 
an interesting and exciting experiment for 
the research participants and the client 
users. 


Acquisition of 
knowledge from expert 
designers 

One of the most critical phases of any 
expert systems project is knowledge ac¬ 
quisition. This is the process whereby 
detailed knowledge is acquired from the 
domain experts for representation in a 
knowledge base inside the computer. In an 
earlier paper, Mittal and Dym 9 discussed 
some of the lessons on acquiring knowl¬ 
edge from experts during the early stages 
of an expert systems project. In particular, 
it was pointed out that there is a need to 
identify clearly the intended users of a pro¬ 
posed system, understand the diversity of 
problem-solving in the domain, exercise 
the experts on representative problems in¬ 
stead of asking them how they solve the 
problems, etc. 

In this section, we describe some of our 
experiences in obtaining more detailed 
knowledge from our experts before the 
PRIDE system was actually implemented. 
We started out by asking our design ex¬ 
perts to collect a set of representative 
design cases. In the next stage we asked 
them to perform detailed designs of the 
selected set of problem specifications. 
During these design sessions, some of 
which we taped for later analysis, we 
started sketching out the outlines of the 
design process that the designers were 
following. 


Knowledge 
acquisition is the 
process whereby 
detailed knowledge is 
acquired from the 
domain experts for 
representation in a 
knowledge base 
inside the computer. 


After the first few design sessions, we 
decided to create a document that would 
explicitly describe what we had learned 
about how our experts designed paper 
transports. The resulting document de¬ 
scribed the different steps they followed, 
how they went about making the decisions 
within each of the steps, the design rules 
that controlled their decisions, and the 
formulae and calculations used along the 
way. After a month of iterating over this 
document, we had something we could cir¬ 
culate to our experts for feedback and 
comments. The revisions took another 
month or so. This document grew to over 
100 pages, including detailed mathemati¬ 
cal analyses, charts, and tables, before we 
started serious programming. 

To test the usefulness and completeness 
of this document before we embarked on 
the next stage of knowledge representation 
on a computer, we asked one of our ex¬ 
perts to design some more paper trans¬ 
ports while we compared their design pro¬ 
cess and the knowledge used with this 
document. Needless to say, many mis¬ 
takes, ambiguities, and gaps in the knowl¬ 
edge were found. A more stringent test 
was for one of us who was not an expert in 
paper transport design to use the paper- 
based version of PRIDE to design paper 
transports for a completely new set of re¬ 
quirements. This test proved to be very in¬ 
teresting and illuminating. First, it pointed 
out that in many cases we had simply 
not questioned our experts hard enough 
to understand the reasoning processes 
behind their decisions—something that 
became painfully obvious when faced with 
a similar design task ourselves. Second, in 
many cases we had let our common sense 
understanding of the domain to bias the 
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Figure 2. A class browser showing the various classes that define the knowledge base in PRIDE. The links from the left to the right 
show a class and its subclasses. Each class defines a set of variables and a set of procedures for defining the behavior. The actual 
knowledge base in PRIDE contains instances of these classes. Thus the goals shown in Figures 3a and 3b are all instances of one 
or the other DesignGoal classes. Similarly, all methods for making the design choices, constraints on the solutions, analytical 
calculations, context of redesign, and advice for fixing the failure are represented by instances of the appropriate class in this 
class lattice (and others not shown). 


knowledge acquisition process. For exam¬ 
ple, in the roll placement subproblem the 
seemingly commonsensical nature of the 
spatial reasoning involved had led us to 
believe that this was a simple subproblem. 
It was only later we discovered that neither 
we nor the experts had a really general ap¬ 
proach to solving this subproblem for all 
the different kinds of constraints. This 
bias was a problem in cases where we had 
mentally locked on to a wrong or ineffi¬ 
cient approach. Another source of prob¬ 
lems was the operational nature of the 
knowledge we obtained from our experts. 
In many cases, the knowledge we obtained 
was operationally worthless because it did 
not specify a computational process for 
making similar decisions. In such cases, we 
had to spend long hours analyzing our ex¬ 
perts’ reasoning process or, worse still, 
devising algorithms for solving the same 
problems. 

It is, perhaps, too early to develop a 
rigorous methodology for acquiring 


knowledge from experts. However, the ap¬ 
proach we followed helped us avoid many 
surprises during the development of the 
actual prototype system and the design 
knowledge document that we prepared 
came closest to acting as a specification for 
the PRIDE system. 


Model of the design 
process in PRIDE 

PRIDE is both an expert system as well 
as a more general designer’s assistant. 
PRIDE is an expert system in the tradi¬ 
tional sense because its knowledge base 
contains the same knowledge that an ex¬ 
pert engineer uses in designing paper 
handling systems. However, unlike a 
typical expert system, the knowledge base 
is not manipulated by an uniform infer¬ 
ence mechanism such as backward or for¬ 


ward chaining of production rules. As we 
describe in the next section, the knowledge 
base contains objects (that is, frames) that 
are organized into well-defined classes 
with appropriate protocols of behavior. In 
simple terms one can think of each class of 
objects as following a separate problem¬ 
solving protocol. In this article we only 
provide an overview of the different kinds 
of design knowledge that are represented 
in PRIDE and the role they play in the 
design process, without going into serious 
knowledge representation or implementa¬ 
tion issues. 

In PRIDE, a design session starts by 
specifying a new design problem or by 
selecting one of the previously stored 
problems. The PRIDE problem solver 
uses the knowledge base to develop a 
paper transport. The problem solver can 
be thought of as following a generate-test- 
analyze-advise-modify paradigm. The 
knowledge base defines a plan for the steps 
to be carried out in a design. Each step 
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describes how to refine the design further 
and how to verify that the design is pro¬ 
gressing along the correct direction based 
on the analysis applicable so far. 

Whenever the design runs into trouble, 
that is, some requirement is not satisfied, 
the problem solver analyzes the current 
partial design, and tries to come up with 
suggestions to overcome the violations. 
There are two complementary approaches 
in PRIDE for modifying a partial design in 
response to problems encountered at later 
stages. The first is heuristic, capturing 
designer’s prior experience in fixing 
similar problems. These heuristics encode 
knowledge about that part of the design to 
modify under what kinds of constraint 
violations. This seems to be sufficient for 
many routine design problems. The sec¬ 
ond method is based on a more general 
problem-solving approach that uses 
dependencies between the different parts 
of a design and the ability to analyze the 
design knowledge to suggest modifica¬ 
tions that go beyond knowledge directly 
represented in its knowledge base. 

We also provide the capability for main¬ 
taining multiple designs simultaneously 
and switching between different partial 
designs (see Mittal et al. 7 for more 
details). Thus, designers (or the system) 
can explore different options in parallel. A 
designer can also selectively undo a design 
or impose additional constraints. These 
exploratory capabilities and the ability to 
critique designs and suggest modifications 
allows PRIDE to act as a designer’s assis¬ 
tant. We believe that design engineers 
working in conjunction with systems such 
as PRIDE can often find suitable designs 
faster than either PRIDE or an engineer 
could have working alone. 

Representation of 
design knowledge in 
PRIDE 

The knowledge base in PRIDE is struc¬ 
tured as a generalized design plan. The 
plan defines the design space and provides 
guidance on how to carry out the design. 
The elements of a plan are the steps to be 
carried out, information about ordering 
the steps, how to perform each step, how 
to detect failures in the design require¬ 
ments, and suggestions for fixing the fail¬ 


ures. The plan is generalized because all 
designs (of paper handling systems in the 
case of the current version of PRIDE) are 
obtained from the same plan when exe¬ 
cuted for a different set of requirements. 
Figure 2 shows the different classes of the 
elements comprising a design plan in 
PRIDE. 


Design goals 

A plan is structured around design 
goals, which decompose the process of 
design into simpler steps. Thus, there is a 
top-level goal in the knowledge base for 
designing the paper transport as well as 
goals for subproblems such as decide num¬ 
ber of roll stations, decide the diameter of 
the driver at station 4, and design the baf¬ 
fle gap. Figure 3a shows the top-level 
design goals in a goal browser and Figure 
3b shows the design goals after the design 
has been partially carried out. Notice that 
more goals were added to the browser as 
the design progressed, reflecting a sort of 
top-down structure of the design plan. 

A design goal, as represented in 
PRIDE, is both a description of some part 
of the overall design, as well as a concept 
around which knowledge is organized. 
Each design goal in PRIDE is responsible 
for designing (and redesigning) a small set 
of design parameters that describe some 
part or aspect of the artifact being de¬ 
signed. In the domain of paper transports 
some design parameters are paper path 
segments; paper path length; number of 
roll stations; diameter, width, and material 
of each pinch roll; baffle gap; baffle 
material; and the time taken by each size 
of the paper during transport. All the 
alternate ways for making a decision 
about a design parameter are attached to 
the same goal. Such decision-making 
knowledge is encoded as design methods. 
Similarly, the knowledge for verifying that 
the solution is indeed acceptable at this 
stage in design is attached to the goal as 
design constraints. It is useful, therefore, 
to think of a design goal as a small, 
autonomous specialist, similar in many 
ways to the notion of a design specialist in 
the representation proposed by Brown 
and Chandrasekaran. 3 

Figure 4 shows a simplified representa¬ 
tion of the goal decide number and loca¬ 
tion of roll stations. In the rest of this sec¬ 


A design goal, as 
represented in PRIDE, 
is both a description 
of some part of the 
overall design, as well 
as a concept around 
which knowledge is 
organized, 


tion we will describe some of the elements 
in representing a goal. Variables such as 
descriptor and name are used to describe 
the goal to the human users. DesignMeth- 
ods is an ordered list of alternate methods 
for achieving the goal. In this example, 
there is only a single method that specifies 
that the way to carry out this goal is to 
achieve four subgoals. These subgoals are 
represented the same way, allowing a 
recursively nested plan. Notice that in this 
example, the method for carrying out the 
goal is itself a plan. However, there are 
many other kinds of methods, described 
later, which directly specify how to make 
the decisions about the design parameters 
of the associated goal. 

Design methods 

A design method specifies how to carry 
out a goal. Figure 2 shows some of the dif¬ 
ferent kinds of design methods. The 
representation of design methods is crucial 
to the problem-solving ability of PRIDE 
because they not only specify how to per¬ 
form one design but collectively specify all 
possible designs. Thus their representation 
is designed to serve multiple purposes. In 
this article we provide only a brief descrip¬ 
tion. Ideally, one would like each design 
method to specify the parameters (design 
variables) that will be assigned new values 
by it; any extra preconditions before the 
method can be run; how to generate a 
suitable value the first time; how to revise 
the value at future times; what the value 
depends on; etc. Unfortunately, not every 
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design parameter can be designed in this 
fashion. Some parts of the design need 
very complex calculations that cannot be 
represented in such a declarative fashion. 
Others may need a complex procedure to 
be followed. Yet others may need the user 
to interact with the system to arrive at 


some suitable design (see Morjaria et al. 5 
for more on the need for interactive 
design). In recognition of this diversity in 
knowledge for carrying out design, we 
provide different kinds of design methods. 
These follow a common minimum pro¬ 
tocol that allows them to interact with the 


attached design goals. We shall illustrate 
the different kinds of design methods by 
way of examples. 

Design generators. The most powerful 
design method from the point of view of 
capturing many design alternatives are the 



subgoal “Design paper path.” These dependencies are automatically computed by the system based on the descriptions con¬ 
tained in the goals. Each goal is also selectable by a pointing device such as a mouse on the screen and presents a menu of com¬ 
mand choices. Some of the commonly used commands are Execute, Undo, Initialize, Edit, and DescribeStatus. 
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Figure 4. Simplified representation of the 
goal “Decide number and location of roll 
stations.” This goal has only one method 
that decomposes the goal into four 
subgoals. For simplicity we have directly 
shown the subgoals, even though they 
are embedded inside a design sequence 
method object. This goal has associated 
with it many other objects such as Con- 
str8, Constr17, and Goal51, each of 
which has its own structure and 
behavior. 


type 

SimpleGoal 

name 

Goal 5 

descriptor 

“Decide number and location of roll stations" 

status 

IN IT 

anteGoals 

“Design Paper Path" 

inputPara 

“PaperPath", “length of PaperPath” 

outputPara 

“Number of RollStations", “location of AIIRolls" 

designMethods 

(subgoals 

Goal51: “Decide min number of rollStns” 

Goal52: “Decide Abstract Placing” 

Goal53: “Generate Concrete Location" 

Goal54: “Build RollStn Structure") 

constraints 

(Constr8: “First Stn < = 100 mm." 

Constr17: “Dist. between adj. stn < = 160mm." 

Constr24: "Dist. between adj. stn > = 50mm.”) 
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type 

InstanceSetGenerator 

name 

SetGenl 

descriptor 

“Generate standard driver diameters” 

assignTo 

(DesignObject defRollPair driver diameter) 

initValue 

“Find a diameter of 10mm” 

classes 

DriverDiameter 

soFar 

NIL 

status 

INIT 


Figure 5. A simplified description of a method for generating the driver diameter by 
looking up a database of standard diameters. 


design generators. These methods are all 
capable of generating different values for 
the same (or a small set of related) design 
parameter(s). It is possible to attach heu¬ 
ristic knowledge with these methods for 
making a “good” guess about the initial 
value to be generated. They also specify 
the ranges of possible values and in¬ 
crements. Figure 5 shows a design 
generator for the goal “design driver 
diameter.” This method generates diame¬ 
ters for the drivers from a known database 
of acceptable driver diameters. This 
special type of generator belongs to the 
class InstanceSetGenerator because the 
database is represented as instances of dif¬ 
ferent classes of objects. In this case, the 
generated objects are instances of Driv- 
erDiameter. The method also specifies that 
a good starting value is a diameter of 10 
mm, presumably because the experts have 
found this to be a good default choice. 
Finally, it specifies that this instance object 
becomes the value of the design parameter 
diameter of the driver. 

Constraints is a list of design constraints 
that must be satisfied for the goal to be 
successful. In this example, there are many 
different constraints, each encoding some 
requirement on the placement of the roll 
stations along the paper path. Finally, 
there are three variables—anteGoals, in- 
putPara, and outputPara—that are used 
to relate this goal to other goals and the 
object being designed. Direct dependen¬ 
cies between goals are represented via 
anteGoals (antecedent goals). Thus, be¬ 
cause we know that the decision about roll 
placement can be made only after design¬ 
ing the paper path, we make the former 
depend on the latter. The problem solver 
ensures that a goal will not be executed 
unless its antecedent conditions (that in¬ 


clude anteGoals and inputPara) are 
satisfied. The variables inputPara and 
outputPara are used to describe the input 
and output behavior of a goal with respect 
to the artifact being designed. Thus, input¬ 
Para describe parts of a paper transport 
that should be designed prior to attempt¬ 
ing this goal. In the example in Figure 3, 
the input design parameters are the ‘ ‘paper 
path” and “length of the paper path.” 
The outputPara describe the parts of the 
design carried out by this goal. In the cur¬ 
rent example, the output design parame¬ 
ters are the “number of roll stations,” 
“locations of AURolls,” and the actual 
objects representing each roll station. In 
many cases, the dependency information 
cannot be expressed statically but needs to 
be computed dynamically. For example, 
depending on the actual design method 
that is tried, the design decisions at a goal 
may depend on different sets of design pa¬ 
rameters. In the PRIDE representation, 
we allow dependencies to be expressed in 
different ways. A detailed discussion of 
how the design parameters are represented 
and actually used and the distinction be¬ 
tween different kinds of dependencies is 
beyond the scope of this article. 

Macro goal. Sometimes the same basic 
design steps have to be repeated, once for 
each member of a set of similar objects. 
For example, the design goals for design¬ 
ing different aspects of roll stations 
(widths, diameters, materials, velocities, 
skew, etc.) contain the same (possibly pa¬ 
rameterized) knowledge that then is 
copied for each roll station. These goals 
are represented in PRIDE as macro goals 
that when executed expand into a set of 
subgoals, one for each of the enumerated 
objects. A macro goal is defined by an 


abstractGoal (the goal being copied) and 
an enumeration expression. 


Design rule group. In some cases, the 
knowledge for making some design deci¬ 
sions requires matching some set of condi¬ 
tions, and can be more easily expressed as 
a set of rules. The design rule group is a 
representation for such knowledge. A rule 
group contains a set of rules and some con¬ 
trol description such as FIRST (stop at the 
first rule whose conditions are satisfied) or 
ALL (execute all rules whose conditions 
are satisfied). Each rule is a set of condi¬ 
tions followed by actions that are 
themselves design methods. Thus, the ac¬ 
tual design knowledge is ultimately con¬ 
tained in other kinds of methods, with the 
rule methods providing some extra control 
information for selecting the proper 
method. Notice that this representation 
explicitly separates the knowledge about 
the different ways to make the design deci¬ 
sions (encoded as the methods in the ac¬ 
tion part) from the control knowledge for 
selecting from these alternatives (encoded 
in the condition part). This allows advice 
to be sent to the relevant methods even 
though the method capable of responding 
may be embedded inside more than one 
level of control. Also, note that since the 
action part of a rule can be any method, 
one can nest rule groups inside other rules 
and rule groups, allowing knowledge to be 
more easily shared. Figure 6 shows the rule 
group for deciding on the number of roll 
pairs at each station. 


Design sequence. So far we have talked 
about decomposing a complex design step 
into simpler design steps without describ¬ 
ing the mechanism in PRIDE for repre¬ 
senting such decomposition. Decomposi¬ 
tion of a goal into subgoals is handled by 
the use of a design sequence method that 
in effect says that the way to perform this 
goal is to execute a set of subgoals. In other 
words, goals do not have subgoals directly. 
The only way to decompose a goal into 
subgoals is to embed the subgoals inside a 
design sequence method and make this be 
one of the methods of the goal. This 
method specifies only a default sequence 
on the subgoals it contains. The actual 
order is computed by the problem solver 
based on the inputPara and anteGoals as 
discussed in the previous section. One con- 
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type 

Design Rule 

name 

Rule 1 

descriptor 

“If input is VCF and first stn then use 1 roll pair" 

status 

INIT 

conditions 

(AND 

(EQ DesignObject (GetPara CurrentPHS firstRoll)) 

(ISA (GetPara CurrentPHS inputSys) ’VCF))) 

actions 

(b) 

(CalcIO: “Set the number of roll pairs to 1 ’’) 


type 

DesignRuleGroup 

name 

RuleGI 

descriptor 

“Decide number of roil pairs per station” 

control 

FIRST 

rules 

(Rulel Rule2 Rule3 Rule4) 

status 

INIT 

(a) 



Figure 6. (a) Description of the rule group for deciding the number of roll pairs for each station. This rule group is run separately for each 
station, (b) Stylized description of one of the rules in the rule group of Figure 6a. The action CalcIO is itself a design method and is 
represented as an instance of the class DesignCalculation. Other rules in the RuleGI are represented similarly. 


sequence of embedding subgoals inside a 
method is that it becomes possible to easily 
specify alternate sets of subgoals for carry¬ 
ing out the same goal or have alternate 
ways of performing some goal only some 
of which involve decomposition into 
subgoals. This is important for represent¬ 
ing, experimenting, and integrating dif¬ 
ferent styles of performing design—an im¬ 
portant objective of our work. 

Some of the other kinds of design 
methods allowed in PRIDE are calcula¬ 
tions (calculating a value from other sets 
of values) and procedures (some closed 
piece of Lisp code that can not be reasoned 
about). The latter are a sort of escape valve 
in the representation in the sense that they 
allow escape to the full power of Lisp in a 
still somewhat principled way. Thus, even 
though design of the paper path requires a 
large and complex piece of Lisp code, it 
can still be reasoned about to some extent 
and used in a principled way by encap¬ 
sulating it inside a design procedure. For 
example, it is possible for the system to re- 
execute this procedure with some advice if 
the paper path needs to be modified or 
wait till the procedure is complete before 
continuing on. 


Design constraints 

The design methods are responsible 
only for suggesting a plausible design and 
not necessarily the best or even a correct 
one. The knowledge about testing and val¬ 
idating a proposed solution is contained in 
the various design constraints attached to 
the goals. There are many reasons for 
making this separation. First, it helps to 
explicitly describe what in fact are two dif¬ 
ferent, albeit related, aspects of the design 


process. An immediate implication of this 
separation is that it allows the same valida¬ 
tion knowledge to be applied regardless of 
which method produced the solution (or 
how the solution was produced). At the 
same time, it does not preclude methods 
from making use of the constraints in 
generating solutions. Some of the design 
methods in the PRIDE knowledge base ac¬ 
tually use some kind of constraint-satis¬ 
faction algorithm in generating possible 
solutions. This is made possible by the ex¬ 
plicit attachment of constraints to the 
same goal that the design methods are at¬ 
tached to. A second important reason for 
this separation is that in some cases a con¬ 
straint can be applied only after two or 
more design parameters have been de¬ 
signed. Thus, instead of making a commit¬ 
ment about the order in which the vari¬ 
ables should be designed, a constraint can 
be placed on some later goal that requires 
only that all the relevant design parameters 
be designed prior to running the goal 
(recall that inputPara serve this purpose in 
the representation of design goals). 

Figure 7 shows a simple constraint from 
the PRIDE knowledge base. The ap- 
plyWhen variable is used to describe the 
conditions under that a constraint is ap¬ 
plicable. The constraint in Figure 7 is 
always applicable but there are other con¬ 
straints that either depend on the specifi¬ 
cations of the particular design problem or 
on the nature of the interfacing systems. 
The variable mustSatisfy is used to specify 
if the constraint can be relaxed if it is not 
satisfied. Currently, we allow only a binary 
choice. In general, it is a hard problem to 
be able to automatically decide which con¬ 
straint to relax. Consequently, we are 
moving toward a position where the user 
would play a larger role in deciding which 
constraints to relax. 


The variable paraConstrained is used to 
describe the dependent variables con¬ 
strained by this constraint object. In this 
case, even though two variables are mutu¬ 
ally constrained, we know from the do¬ 
main experts that the width of the idler is 
the dependent variable. Since this is an ex¬ 
ample of a constraint on a single variable 
(as indicated by the type), the actual con¬ 
straint expression is composed from the 
predicate paraConstrained, and the 
testExp (test expression) variables. Other 
kinds of constraints have other ways of 
composing the constraint expression. 

Often some very complex analyses 
might be behind the test expression used to 
constrain the designed variables. In the 
PRIDE representation scheme, we have 
also provided an explicit way to describe 
the calculations behind such validation 
analyses. This allows, for example, some 
advice for fixing a constraint violation to 
be recursively back-propagated through 
the calculation expression. In other words, 
the advice on some constraint whose 
variables are themselves calculated can be 
converted into further advice based on an 
analysis of the calculation expression. 
Another advantage for explicitly repre¬ 
senting the calculation is that any explana¬ 
tion that is produced for the design choice 
can state the mathematical formula in¬ 
stead of just computing the value. 


Modification of a 
design 

What should happen when a constraint 
fails? Answers to this question are crucial 
to the system’s ability to help a designer. 
As part of the PRIDE project, we are in- 


July 1986 










type 

SingleConstraint 

name 

Constraint29 

description 

"Idler width >= 1.2 times driver width” 

applyWhen 

ALWAYS 

mustSatisty 

YES 

abstractable 

YES 

paraConstrained 

(DesignObject defRollPair idler width) 

predicate 

GEQ 

testExp 

(TIMES 1.2 

(GetPara DesignObject defRollPair driver width) 

adviceCntxt 

ALWAYS 

advice 

(Increase (DesignObject defRollPair idler width)) 

(Decrease (DesignObject defRollPair driver width)) 


Figure 7. Sylized description of the constraint “idler width > =1.2 times the driver 
width.” The actual advice and advice context are represented by seperate objects. 


vestigating many different aspects of this 
problem and will be reporting in detail in 
later papers. Here we shall briefly outline 
some of the mechanisms employed in 
PRIDE toward this end. 

In generate-and-test models such as 
Dixon and Simmons’s, 1 a failure leads to 
a new round of design activity where the 
system can presumably generate a new 
design to be tested again. More sophisti¬ 
cated approaches employ some kind of 
backtracking mechanism to unwind to a 
prior decision point and continue from 
there. For example, in the dependency- 
directed backtracking schemes, 14 the 
problem solver maintains an explicit 
record of the dependencies between a deci¬ 
sion and the basis for making the decision. 
These dependencies can be used to unwind 
to a relevant prior decision point. The ad¬ 
vantages are that only a small part of the 
design needs to be undone when some con¬ 
straint violations are detected. However, 
most of these approaches do not address 
the issue of how to modify the decision 
that was identified as a culprit in some 
failure (or a contradiction in deductive 
reasoning). 

The problem solver in PRIDE is based 
on dependency-directed backtracking 
with an important extension. We allow ad¬ 
vice to be sent to the problem solver by the 
constraint that failed. In many cases, this 
advice is meant for some prior decision 
point, telling it how to modify its decision. 
In more complex cases, the advice can af¬ 
fect many decision points, or even the 
problem solver itself. Often it happens 
that more than one advice is applicable at 


some point and the system (or the user) 
might want to explore the consequences of 
following the advice in parallel. This is 
enabled in PRIDE by a multiple contexts 
mechanism that allows a tree of related 
contexts to be created. The recent work on 
assumption-based truth maintenance sys¬ 
tems 15 may also be relevant in this regard. 
In order to follow the advice, the problem 
solver has to figure out that goal to advise, 
how to minimally undo the dependent 
design, how to preserve the context of the 
original failure, and how to select from 
competing or partially satisfactory advice. 
Lack of space does not permit a detailed 
discussion of these mechanisms. It is im¬ 
portant, however, to point out that the ap¬ 
proach taken by Brown and Chandrase- 
karan 3 finesses many of these issues by 
making two simplifying assumptions. 
First, they assume that the target of the ad¬ 
vice is always known in advance, some¬ 
thing tenable only for some design prob¬ 
lems. In particular, this assumption is valid 
only when the structure of the designed ar¬ 
tifact is fixed in advance. Clearly, this is 
not true for artifacts, such as paper trans¬ 
ports, that have a variable structure; that 
is, the structure is itself designed. Second, 
they assume that the advice will be carried 
out successfully, thus obviating the need 
for maintaining the context or making 
choices. This assumption is again unten¬ 
able for many real design problems where 
the process of finding one or more suitable 
designs involves an exploration of choices. 

In the rest of this section we examine 
how advice is generated and represented in 
PRIDE. Sometimes, advice may be ob¬ 


tained from experts in advance because 
they learn from experience what the 
typical failures are and how some of them 
may be fixed. These can be represented in 
PRIDE by using the adviseCntxt and 
advice attached to each constraint. The 
adviseCntxt contains knowledge for 
analyzing the failure and advice points to 
suggestions for fixing the failure. For ex¬ 
ample, in the constraint shown in Figure 7, 
there is only one context, namely, “al¬ 
ways,” which contains two different 
pieces of advice. These advise the problem 
solver, respectively, to try to increase the 
width of the idler or to decrease the width 
of the driver. 

In order to provide a more general 
framework for exploring the design space, 
something that we believe will provide im¬ 
portant leverage to a designer, the system 
must be able to go beyond the advice ex¬ 
plicitly made available by the experts. The 
system, in effect, must be able to reflect on 
its knowledge, analyze the cause of the 
failure, and then automatically generate 
advice (or a plan in more complicated 
cases) to repair the failure. We have made 
some progress in being able to analyze 
constraint expressions and the calculations 
underlying those constraints and automat¬ 
ically generate advice over and beyond 
what was provided by the experts. The 
mechanisms and knowledge representa¬ 
tions required to support this kind of 
reasoning, the many open issues, and 
some of the early experiences with this 
more general capability are beyond the 
scope of this article and will be discussed in 
later papers. 

There are many other unresolved issues 
relating to the role of constraints in the 
design process. Some of these issues deal 
with maintaining the consistency of a 
design under a set of constraints. In other 
words, once some design choices have 
been made that satisfy a set of constraints, 
how does one ensure that either none of 
those choices will be modified individual¬ 
ly, or that the effect of modifying one of 
the choice variables will be propagated to 
all the other constrained variables. PRIDE 
has proved to be an excellent test bed for 
investigating some of these issues. Anoth¬ 
er issue deals with efficiently generating all 
possible solutions under a set of con¬ 
straints so that these solutions can be ex¬ 
amined by other more complex con¬ 
straints. Some of the early results on this 
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problem are described elsewhere by Mittal 
and Stefik. 8 

Implementation, testing, 
evaluation, and current 
status 

Implementation. PRIDE is imple¬ 
mented in Loops 16>17 running on a Xerox 
1100 series Lisp machine. Loops is a mul¬ 
tiparadigm knowledge programming lan¬ 
guage developed at Xerox PARC and im¬ 
plemented in and as an extension of 
Interlisp-D. 18 Loops provides a very rich 
programming environment for building 
and experimenting with different knowl¬ 
edge representation and problem-solving 
schemes. In implementing the PRIDE sys¬ 
tem, we have made good use of these 
facilities. The different elements of the 
knowledge representation scheme, as 
described earlier, are all implemented as 
classes of objects. Thus each design goal, 
method, constraint, adviseContext, ad¬ 
vice, and calculation are represented as 
distinct objects. Furthermore, the paper 
handling system being designed is itself 
represented as a collection of intercon¬ 
nected objects. 

The behavior attributed to these objects 
in the previous section is made operational 
by defining (and implementing) a set of 
messages by which these objects com¬ 
municate with each other. For example, 
each design method object responds to a 
CarryOut message by trying to perform 
the design if at all possible, otherwise 
replying suitably. Different classes of 
design methods carry out the design in dif¬ 
ferent ways. For example, a generator tries 
to generate a value and assigns it to the 
associated design parameter. On the other 
hand, a design sequence method posts its 
subgoals on the problem solver’s agenda 
and suspends itself and its supergoal. 
However, a design goal does not have to 
know how a design method will work. It 
needs only to interpret the different 
responses from the design methods. 
Notice that this style of knowledge pro¬ 
gramming is very different from the rule- 
based approaches. It offers more flexibili¬ 
ty in representing different kinds of 
knowledge and enables a knowledge pro¬ 
grammer to make explicit the role of some 
piece of knowledge in a problem-solving 


activity. Forcing all knowledge in the form 
of rules and running a uniform inference 
procedure over them often obscures the 
intent and, contrary to claims, makes the 
use of the same knowledge for different 
purposes very hard. 

The current knowledge base in PRIDE 
for pinch roll paper transports is roughly 
80 percent complete and comprises close 
to a thousand objects. The knowledge 
base objects along with all the supporting 
Lisp code currently take up over 2M bytes 
of memory, over and beyond what Loops 
and Interlisp-D take. Part of the reason 
for the size of the system is the complexity 
and size of the design domain. A sizable 
part of the code (at a rough estimate as 
much as 40 percent), however, was taken 
up by the many user-interface facilities 
that were developed to either support a 
design engineer during a design session or 
to support a knowledge engineer in the 
creation and maintenance of the object- 
oriented knowledge base. 

Testing and evaluation. PRIDE has 
been tested on over a dozen real paper 
transport problems from previous and 
current copier projects. It has come up 
with satisfactory designs in many of those 
cases. In fact, engineers working with the 
PRIDE system have been able to come up 
with more than one satisfactory design for 
some of the problems. In a test involving 
one of the currently ongoing copier proj¬ 
ects, we were able to modify PRIDE to 
first accept the design produced by the 
project engineers and then test it. The 
analysis produced by PRIDE showed 
some key drawbacks in the design that 
were later confirmed by the project engi¬ 
neers. Later, PRIDE was able to come up 
with a different design that satisfied the 
design considerations in its knowledge 
base. The system is beginning to be used in 
support of selected on-going copier proj¬ 
ects and we expect to report on the perfor¬ 
mance in later papers. 

Another measure of its effectiveness is 
the time required to produce a design and 
the thoroughness of the analyses per¬ 
formed on the design. Our experience is 
that systems such as PRIDE will be very 
effective in this regard. PRIDE can pro¬ 
duce a design in 30 minutes that typically 
takes an engineer many weeks to perform. 
Furthermore, the analysis performed by it 
and the report generated are more com¬ 
plete than current practice. 


W e are still in the early stages of 
evaluating the system. How¬ 
ever, it has “proved” to be 
useful enough that the user organization 
(RBG, the copier unit of Xerox) has de¬ 
cided to set up their own support group for 
the PRIDE system. It is unlikely that 
statistical comparisons of PRIDE’S per¬ 
formance with that of design engineers will 
prove to be very helpful by themselves. 
Success of systems such as PRIDE will be 
as much determined by technical com¬ 
petence as by the creation of a user com¬ 
munity that can collectively play a role in 
defining the scope of the system, in 
validating the knowledge, and in other 
ways using the system as an effective 
knowledge medium. □ 
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needed t 
expert systems 
technology for 
application to the 
SDI environment but 
its potential for 
helping to fulfill the 
SDI is gre 



F irst there was the Manhattan 
“atomic bomb” project in the 
1940s. Then, the Apollo project in 
the 1960s landed men safely on the moon. 
Now, in the 1980s, a “Strategic Defense 
Initiative,” or “SDI,” is underway whose 
goal is to counter the terrible threat of 
nuclear ballistic missiles. 

Artificial intelligence techniques and 
supercomputer use will have to play influ¬ 
ential roles in order for the Strategic De¬ 
fense Initiative to become a success. In 
particular, expert systems could have a 
major impact in meeting the objectives of 
the SDI project. 

Expert systems are computer programs 
that emulate the behavior of human ex¬ 
perts in a specified domain of knowledge. 
They have been developed for many func¬ 
tions: diagnosis, data analysis and inter¬ 
pretation, design, planning, learning from 
experience, concept formation, signal in¬ 
terpretation, monitoring, computer-aided 

The work reported in this article was performed while 
Chien was with the Navy Center for Applied Research 
in Artificial Intelligence, Naval Research Laboratory. 
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instruction, tutoring, knowledge acquisi¬ 
tion, image understanding, and others. In 
the defense environment, expert systems 
have been constructed for battle manage¬ 
ment (for example, BATTLE, 1 GENIE, 2 ), 
command and control (for example, 
DEVISER, 3 NAVEX, 4 RENEX, 4 and 
KNOBS 5 ), analysis (for example, 
TECH 5 ), and multisensor information in¬ 
tegration (for example, ANALYST, 6 and 
HASP/SIAP 7 ). 

Expert systems 
definition and defense- 
related expert systems 

An expert system is a computer pro¬ 
gram that mimics the behavior of human 
experts within a specific domain of knowl- ( 
edge. 8 Edward Feigenbaum, 9 one of the 
pioneers m expert ~5ystem s, provi des a 
more coinpieliensrve-eXpert system defini¬ 
tion: 

An expert system is an intelligent 

computer program that uses knowledge 


















The merit system is a 
best-first strategy in 
which questions that 
are highly relevant 
and easy for the user 
to answer are asked. 


and inference procedures to solve prob¬ 
lems that are difficult enough to require 
significant human expertise for their 
solution. The knowledge necessary to 
perform at such a level, plus the infer¬ 
ence procedures used, can be thought of 
as a model of the expertise of the best 
practitioners in the field. 

In the past, expert systems have general¬ 
ly worked well in problem areas with ill 
and unstructured aspects, as shown by the 
following characteristics: 10-14 

• There existed at least one expert in the 
problem area who is generally acknowl¬ 
edged as such. 

• The sources of the expert’s expertise 
were judgment and experience—knowl¬ 
edge that could be ‘ ‘taught ” to a computer 
program. 

• The expert was able and willing to ex¬ 
plain his/her knowledge to a knowledge 
engineer. 

• The problem was well-bounded to 
prevent an unmanageably large search 
space. 

• The problem area had a real consen¬ 
sus, not, for example, macroeconomic 
policy. 

• Test data was easily available 

Defense-related expert systems. Before 
fully discussing the SDI environment, it 
might be helpful to briefly explain some of 
the expert systems that have been devel¬ 
oped for defense-related functions. 

BATTLE 1 is one such expert system 
that was developed by the US Navy Center 
for Applied Research in Artificial In¬ 
telligence. BATTLE’S primary objective is 
to provide recommendations for the allo¬ 
cation of a set of weapons to a set of 
targets. It first determines the effec¬ 
tiveness of each weapon-target allocation 


and then applies the effectiveness to 
evaluate complete allocation plans. 1 
BATTLE uses a pruning algorithm to 
eliminate plans to determine the optimal 
solution or a suboptimal (for example, 
perhaps 98 percent optimal) allocation. 1 
The decision for the optimal solution ver¬ 
sus a suboptimal solution is mainly a 
trade-off between destruction value and 
time. 1 For example, the optimal solution 
for the allocation of eight weapons to 
seventeen targets took approximately 12 
minutes in a research setting; whereas, the 
98 percent suboptimal solution took about 
7 seconds. 1 

A major breakthrough exhibited in 
BATTLE’S inference engine is the use of a 
computation network. This computation 
network is an enhancement to the in¬ 
ference network used in PROSPECTOR. 2 
BATTLE’S network not only has nodes 
that represent propositions with proba¬ 
bility-like values, but also allows nodes 
that represent arbitrary numeric quan¬ 
tities. 2 This network determines how cer¬ 
tain values are computed to update the 
database. 1 It propagates information, 
allows forms of information other than 
probabilities, provides inferencing about 
an unlimited number of objects (the 
weapons and targets), and permits the 
classification of those objects into types. 1 
Besides the computation network, a pro¬ 
cedure called the “merit system” is used to 
intelligently direct the acquisition of infor¬ 
mation. 1 The merit system is a best-first 
strategy in which questions that are highly 
relevant and easy for the user to answer are 
asked. The merit system is being extended 
to include: 15 defining and using merit 
relative to any ancestor node, not just to a 
top node, and handling merit for potential 
finite changes to the value. Further work is 
contemplated on using merit for a directed 
acyclic graph (not just a tree), and having 
merit handle the propagation of distribu¬ 
tions (not just single values). 15 

Once the individual effectiveness values 
are found in the first phase, then a pruned 
tree searching algorithm is used to gener¬ 
ate and select the best allocation plans, 
that is, a composite allocation plan that 
maximizes the expected total destruction. 1 
This is the second phase of BATTLE. 

ANALYST 6 is another defense-related 
expert system, and it is used for processing 
sensor returns. ANALYST was developed 
by MITRE Corporation and it processes 


reports from multiple sensor sources to 
produce transient situation displays of 
enemy combat units in real time. 6 Specifi¬ 
cally, ANALYST aggregates products 
from multiple sensor sources to locate and 
classify enemy battlefield units in real 
time, detects and integrates force move¬ 
ment so as to maintain a dynamic por¬ 
trayal of the enemy situation, and requires 
only a microprocessing environment in 
which to operate. 6 

The ANALYST efforts have resulted in 
six knowledge bases concerning the pro¬ 
cessing of sensor reports into an enemy 
tactical order of battle. 6 The knowledge is 
represented via frames and rules. Manipu¬ 
lation of the knowledge is accomplished 
through the chronological ordering of 
rules for clustering, patterning, merging, 
checking, reinforcing, and purging. 6 
Preliminary results show that ANALYST, 
given sensor reports representing less than 
20 percent of the battlefield observables, 
can detect and classify over 50 percent of 
the enemy units in range. 6 ANALYST can 
operate on the Apple, Lisp machine, and 
VAX 11/780. 

HASP, 7 and its follow-on, SIAP, 7 are 
early examples of defense-related expert 
systems. HASP was developed at Stan¬ 
ford University and its goal is the inter¬ 
pretation or understanding of signal data. 
It was designed for ocean signal under¬ 
standing. SIAP—an improvement on 
HASP—automates the process of identi¬ 
fying and characterizing line segments 
used in signal data. 

HASP/SIAP, through using data from 
concealed hydrophone arrays, must 
detect, localize, and ascertain the type of 
each ocean vessel within range. 7 The 
knowledge is represented in rules, and 
both data-driven and model-driven 
hypothesis-formation techniques are 
used. The knowledge represented in 
HASP/SIAP refers to: 7 

• knowledge about the environment, 

• knowledge about vessels, 

• interpretation knowledge, and 

• knowledge about how to use other 
knowledge (meta-knowledge). 

From inputs mainly of a sequence of 
described line segments and information 
from various reports, HASP/SIAP devel¬ 
ops output of a data structure containing 
the program’s best explanation of the cur¬ 
rent input data considered in conjunction 
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with previous analyses of earlier-received 
data. 7 

DEVISER 3 is another expert system 
that could be applied to defense-related 
issues, namely command and control. 
DEVISER was developed at the Jet Pro¬ 
pulsion Laboratory. It is a general- 
purpose automated planner/scheduler. 
DEVISER synthesizes plans to achieve 
goals that may have time restrictions on 
when sets of goals should be achieved and 
on how long the goal conditions should be 
preserved. 3 DEVISER was originally de¬ 
veloped for planning and scheduling ac¬ 
tions for autonomous unmanned space¬ 
craft, such as those used in the Voyager 
mission. 

The key output of DEVISER is a par¬ 
tially ordered network of activities. 3 
DEVISER uses the style of discrete event 
simulation systems, such as SIMSCRIPT, 
in which all changes can be assumed to oc¬ 
cur at specific points in time, rather than 
continuously as in continuous time simu¬ 
lations. 3 However, the program is quite 
different from discrete simulation systems 
because it is goal-directed and generates its 
activities in reverse time order. 3 

There are many other expert systems 
that have been developed for defense- 
related applications. A few of these are: 

• one developed by Systems Develop¬ 
ment Corporation for tactical assess¬ 
ment of multisource messages, even 
radar (STAMMER), 


• one developed by MIT for image 
understanding (ACRONYM), 

• one developed by the Navy Center for 
Applied Research in Artificial In¬ 
telligence for electronic maintenance, 
and 

• one developed by ESL/TRW for 
tactical indications and warning 
analysis. 

Description of the SDI 
environment 

The Strategic Defense Initiative, or 
SDI, was formed in response to President 
Reagan’s speech on March 23, 1983 in 
which he urged the United States to in¬ 
vestigate whether new technologies could 
provide the means for countering the 
awesome threat of nuclear ballistic 
missiles. The President said: 16 

Tonight, consistent with our obliga¬ 
tions of the Anti-Ballistic Missile 
(ABM) treaty and recognizing the need 
for closer consultation with our allies, 
I’m taking an important first step. I’m 
directing a comprehensive and intensive 
effort to define a long term R&D pro¬ 
gram to begin to achieve our ultimate 
goal of eliminating the threat posed by 
strategic nuclear missiles. This could 
pave the way for arms control measures 
to eliminate the weapons themselves. 


In order to develop an effective defense 
against ballistic missiles, several pro¬ 
grams 17 were proposed in the areas of 

• surveillance, acquisition, and track¬ 
ing, 

• directed energy weapons, 

• conventional weapons, 

• battle management, communica¬ 
tions, and data processing, 

• systems concepts, and 

• countermeasures and tactics. 

These programs would help to accomplish 
the goal of the SDI. 

An essential component of the SDI is 
the use of a layered defensive system. This 
multitiered defense system would com¬ 
prise the Ballistic Missile Defense, or 
BMD. These layers refer to the ballistic 
missile’s boost, midcourse, and terminal 
phases. Figure 1 depicts these phases in a 
sample scenario. 18 In the boost phase, the 
rocket engines accelerate the missile pay- 
load through and out of the atmosphere, 
whereafter multiple warheads and pene¬ 
tration aids are released from a post-boost 
vehicle (bus deployment). It is most im¬ 
portant to destroy the missiles during the 
boost phase, because each “kill” would 
eliminate the need to deal with many 
warheads and decoys later. A missile re¬ 
mains in the boost phase for about 3 
minutes, whereafter multiple, indepen¬ 
dently targetable reentry vehicles, or 
MIRVs, are deployed by the missile during 
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Metaknowledge can 
improve the 
performance of the 
program by 
constraining the 
search for a solution. 


the next approximately 8 minutes, in 
which 10 real warheads and 100 decoys 
could be released. In the midcourse phase, 
during the next approximately 15 minutes, 
the warheads and penetration aids travel 
on trajectories above the atmosphere, in 
which there are bombs and decoys. Sen¬ 
sors must distinguish live reentry vehicles, 
or RVs, from decoys, destroyed RVs, and 
debris. During the next 3 minutes, in the 
terminal phase, the warheads reenter the 
atmosphere, where they are affected by at¬ 
mospheric drag. In each phase, a defensive 
system must perform three basic func¬ 
tions: first, surveillance, acquisition, and 
tracking; second, intercept and target de¬ 
struction; and third, battle management. 19 

In order to destroy the missiles, several 
weapons have been proposed. Some of 
these include: 

• kinetic-energy weapons (“smart 
rocks”—a self-guided projectile that 
homes in on a missile or an RV and slams 
into it) and 

• directed-energy weapons (emit pow¬ 
erful beams that can knock a target off 
course, destroy its electronics, or partially 
melt it) such as neutral-particle beam, 
chemical laser (space or ground-based), 
and X-ray laser. 

Battle stations, perhaps as many as 100, 
might have to be built. 18 A battle station 
might contain a weapon concentrating 
millions of watts of energy in a beam that 
would bounce off a 30-foot-wide mirror 
that swirls to aim at a series of rockets and 
warheads. 18 

In order for this Ballistic Missile 
Defense system to exist, several critical 
technologies must be examined. These 
areas are identified by the Defensive 
Technologies Study Team 17 as: 


• Threat Clouds—dense concentra¬ 
tions of reentry vehicles, decoys, and 
debris in great numbers must be identified 
and sorted out during the midcourse phase 
and high reentry. 

• Survivability—a combination of tac¬ 
tics and mechanisms must be developed to 
ensure the survival of the system’s space- 
based components. 

• Boost and Post-Boost Phases—the 
ability to effectively respond to an un¬ 
constrained threat is strongly dependent 
on meeting that threat appropriately dur¬ 
ing the boost and post-boost phases. 

• Interceptors—interceptors must be 
economical enough to permit attacks on 
threatening objects that cannot be dis¬ 
criminated. 

• Battle Management—tools are 
needed for developing battle management 
software. 

Near-term demonstrations of possible 
technologies in the BMD environment 
could perhaps be shown. Among these 
technologies is the use of expert systems in 
the BMD environment. 


Key characteristics 
expert systems should 
possess for SDI work 

In designing expert systems in the SDI 
environment, requirements for these ex¬ 
pert systems must first be identified. 
Although many requirements for these 
systems will evolve over time as new 
discoveries are made and new technologies 
result, an attempt to presently identify 
some of the key characteristics that an 
SDI-related expert system should possess 
will be made. 

First, it should be “evolvable,” that is, 
easy to modify and update. This refers to 
two important areas: modularity and 
knowledge acquisition/maintenance. The 
expert system should follow a top-down, 
modular design where modules are used to 
hide design decisions and, through their 
use, later changes in the design are easy to 
make. 20 To further ease modification and 
updating, a function for knowledge ac¬ 
quisition/maintenance should be incor¬ 
porated into the expert system. This is to 
insure that the knowledge base can easily 
be kept current, complete, and accurate. It 
would also be useful to have a semiauto¬ 
matic knowledge acquisition facility, 


perhaps based on a natural language ex¬ 
planation capability in order to alleviate 
the knowledge acquisition bottleneck. 21 

Second, the control procedure must be 
designed so that the expert system can 
“reason” effectively and quickly within 
the time-critical constraints of the missile’s 
phases. A best-first strategy like the 
“merit system” might be a first attempt to 
develop this control procedure. The merit 
system minimizes the amount of work and 
time required to enter the highly relevant 
information, and experience has shown 
that it produces significantly better results 
than more traditional algorithms. 22 - 23 
Slagle’s works 1,15 ’ 22 best describe the 
merit system. 

Third, it should have the capability for 
having both forward and backward rea¬ 
soning. Forward chaining is a problem¬ 
solving paradigm in which chaining starts 
from a set of conditions and moves toward 
some (possibly remote) conclusion. 24 ’ 25 
Backward chaining entails having a goal 
or a hypothesis as a starting point, and 
then “working backwards” along some 
paths to see if the conclusion is true. 24 
Forward and backward reasoning are 
both particularly important in the mul¬ 
tisensor information integration and dis¬ 
tributed problem solving aspects of the 
SDI environment. 

Fourth, the expert system should con¬ 
tain many user-friendly features such as an 
explanation facility, free-text comments, 
questioning, help facilities, menus, and 
some natural language capabilities. An ex¬ 
pert system is not just a set of rules that are 
processed to determine a solution. An ex¬ 
pert system must incorporate user-friendly 
features in order to make it easier to use, 
thus creating a smooth implementation. 
These aforementioned user-friendly fea¬ 
tures are essential elements in an expert 
system and should be included in the SDI- 
related expert system. 

Fifth, the expert system should be able 
to reason probabilistically (or possibilisti- 
cally). In weapon to target allocation, in¬ 
put attributes (for example, location of 
targets) are usually not known with 100 
percent certainty. Thus, uncertainty must 
be taken into account in the design of the 
expert system. 

Sixth, it should be flexible enough to be 
able to use metaknowledge. Metaknowl¬ 
edge refers to knowledge about the knowl¬ 
edge in the program. 26 Metaknowledge 
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can improve the performance of the pro¬ 
gram by constraining the search for a 
solution. 26 

Seventh, the system should be responsi¬ 
ble for consistency checking and the in¬ 
tegration of the new information with the 
old. The expert system development 
engine should be responsible for aiding in 
the checking for consistency and com¬ 
pleteness of the rules and facts in the 
knowledge base. Verification of program 
correction is also needed. 

Eighth, it should be kept as small as 
possible, but powerful enough to meet the 
necessary requirements. 

Ninth, the design of the expert system 
must take into account a massively distrib¬ 
uted ballistic missile defense system 
architecture. 

Tenth and last, the expert system must 
be capable of supporting qualitative rea¬ 
soning about a physical/causal system. 21 

Indeed, a great deal of basic research is 
needed in qualitative reasoning, knowl¬ 
edge base encoding and search, plausible 
reasoning, user interfaces, and knowledge 
acquisition to improve the state of the art 
in order to develop expert systems to 
handle the BMD environment for the 
1995-2000 outlook. 


Areas for possible 
expert system 
development in the SDI 
environment 

In terms of NCARAI’s (US Navy 
Center for Applied Research in Artificial 
Intelligence) interests, there are four fruit¬ 
ful areas for expert system applications in 
the SDI arena. These areas include: 

(1) software requirements determina¬ 
tion, 

(2) multisensor information integration, 

(3) battle management, and 

(4) distributed problem solving. 

Software requirements determination. 

According to a study by Kestrel Insti¬ 
tute, 27 a need exists for a knowledge- 
based software assistant. This knowledge- 
based software paradigm of the future will 
provide a set of tools and capabilities inte¬ 
grated into an “assistant” that directly 
supports the human developers in the re¬ 
quirements analysis, specification, imple¬ 
mentation, and maintenance processes. 27 


The long-term goal of the requirements 
part of this assistant is to provide: 27 

• comprehensive requirements man¬ 
agement, 

• intelligent editing of requirements, 

• testing of requirements for com¬ 
pleteness and consistency, 

• performing requirements reviews, 

• maintaining and transforming re¬ 
quirements in response to changes, 

• decomposing and refining require¬ 
ments into executable specification 
languages, and 

• acquiring requirements knowledge. 

To accomplish this long-term goal, various 
short-term and mid-term goals must first 
be realized. 

The short-term goals include: 27 

• Analysis of Requirements Problem 
Definition—a planning phase should be 
conducted to review and refine the short-, 
mid-, and long-term goals. 

• A Formal Requirements Language— 
an initial requirements language should be 
designed that allows a combination of for¬ 
mal specifications and text strings. 

• Smart Editing and Managing of Re¬ 
quirements—an intelligent editor should 
be constructed to be used for creating and 
modifying requirements definitions. 

• Reviewing Requirements Definitions 
for the User—the user should view the re¬ 
quirements in a new light and possibly see 
problems or opportunities. Review meth¬ 
ods could include paraphrase in natural 
language, graphic displays of domain 
models in the knowledge base, etc. 

• Requirements Testing—a first set of 
requirements tools should be built for 
checking for a simple heuristic kind of 
consistency and completeness. 

The mid-term goals include: 27 

• Incorporating Domain Knowledge 
into the Requirements Capabilities—sim¬ 
ple models of frequently used domains 
should be developed. The models will sup¬ 
ply the knowledge base that will be used 
for domain-specific support of the re¬ 
quirements capabilities. 

• An Automated Structured Walk- 
Through System for Requirements Engi¬ 
neering—a structured walk-through tool 
based on a fault model representation and 
on a requirements language will aid an ex¬ 
pert systems analyst to keep track of loose 
ends and problem areas. 


Tutoring will help new 
members of the 
software design team 
to learn to use the 
software assistant's 
capabilities. 


• Requirements Transformation and 
Refinement—techniques from knowl¬ 
edge-based program synthesis could be 
extended to allow transformations of re¬ 
quirements. 

• A Requirements Tutor—tutoring will 
help new members of the software design 
team to learn to use the software assistant’s 
capabilities. 

The above goals are quite ambitious, 
but they are the steps needed to formalize 
and improve requirements definition, 
completeness, consistency, and validation. 
Developing a knowledge based software 
assistant is a critical area in the SDI en¬ 
vironment because it must cope with re¬ 
quirements that will be evolving over the 
next 15 years. 28>29 This software assistant 
would help in formalizing the SDI ar¬ 
chitecture and battle management de¬ 
fense. Thus, a tool to check the consisten¬ 
cy, accuracy, completeness, and testability 
of these requirements would greatly aid in 
building a strong battle management 
defense system. 

Multisensor information integration. A 

second critical area deals with multisensor 
information integration. This involves de¬ 
veloping an expert system or related 
technology for the timely acquisition, 
tracking, and discrimination of a large 
number of objects in space. These objects 
include targets, decoys, and a variety of 
penetration aids. Technologies used for 
conventional targets (for example, trucks, 
airplanes, etc.) are not directly applicable 
to space systems for at least three reasons. 
First, objects, sensors, and weapons are 
likely to have complex motion relation¬ 
ships in space systems. The simplified 
assumptions regarding the relative motion 
between targets and sensors/weapons in 
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conventional systems cannot be made. 
Second, in most conventional systems, 
target signatures or images obtained from 
sensors are assumed to have a fixed resolu¬ 
tion. In a space system, acquisition, track¬ 
ing, and discrimination may best be car¬ 
ried out in different stages based on 
signatures/images of different resolu¬ 
tions. Third, the number of objects that a 
space system must deal with is expected to 
be extremely large compared to the rela¬ 
tive few in most conventional systems. 

In order to combat these problems, 
work is needed to create 1990s’ techniques 
for acquisition, tracking, discrimination, 
and weapon engagement as well as to de¬ 
velop knowledge-based techniques for 
multisensor integration in the battle 
management defense environment (that 
is, infrared, radar, optical, and other sen¬ 
sors). Specifically, the development of 
signature/image algorithms for target 
discrimination is needed, and the use of ar¬ 
tificial intelligence for knowledge-directed 
sensor management must also be investi¬ 
gated. The latter activity involves expert 
system development for sensor manage¬ 
ment of single versus multiple sensors and 
for staged discrimination. Again, expert 
system building for these purposes is an 
ambitious and arduous task, but is greatly 
needed to meet the goals of an effective 
and efficient battle management defense 
system. 

Battle management. The third area for 
possible expert systems application deals 
with battle management functions. Any 
system that is deployed to meet the ex¬ 
pressed aims of the SDI will clearly have to 
incorporate unprecedented levels of archi¬ 
tectural and information-processing com¬ 
plexity. It would contain symbolic descrip¬ 


tions of items such as what the individual 
hardware, software, and communications 
components of the BMD system are; how 
they operate internally; how they are tied 
together; and how they are expected to 
function in the event of an attack. The sys¬ 
tem should also have these descriptions as 
complete as the understanding of the 
human experts who engineered each com¬ 
ponent and their interconnections. Final¬ 
ly, the system should be evolvable, to 
change as the BMD system itself changes. 
The system and its interface to its use 
could be used to assist in the battle 
management task. More importantly, its 
applications should be in routine status, 
training, maintenance, trouble-shooting, 
reconfiguration tasks, as well as support¬ 
ing the generation and modification of 
software associated with the battle 
management functions. 

Support is needed to: 

• develop techniques for representing 
the knowledge associated with all battle 
management defense assets (sensors, 
weapons, command/control/communi¬ 
cations, etc.); 

• determine the interrelationships 
among these assets; 

• develop computational requirements 
for manipulating the assets and their rela¬ 
tions in battle management defense (for 
example, system configuration and recon¬ 
figuration); and 

• develop techniques for using the 
knowledge model(s) for assisting in the 
generation and verification of computer 
software (algorithms, controls, and com¬ 
putation structures). 

Specifically, expert system support is 
needed for software development, mainte¬ 
nance, testing, evaluation, and system 
simulation. 

Distributed problem solving. The 

fourth area of interest in SDI-related ad¬ 
vances in technology concerns distributed 
problem solving. One of the key architec¬ 
tural requirements for battle management 
in the BMD system is survivability and 
performance with graceful degradation. 
Every platform in the system is a problem¬ 
solving agent that must be able to govern 
its own actions—in concert with a large 
number of other platforms—given incon¬ 
sistent, inaccurate, uncertain, or incom¬ 
plete information. Artificial intelligence 
researchers have investigated these issues 


in their work on distributed problem solv¬ 
ing. In the BMD environment, however, 
distributed problem solving poses several 
difficulties that need further study: coher¬ 
ence of the overall processes, synchroni¬ 
zation of problem-solving activity, tech¬ 
niques for interagent communication, 
“grain-size” of communicated messages, 
balancing of processing load across system 
resources, and so on. The research done to 
date has studied these issues in domains re¬ 
quiring a dozen agents. The anticipated 
need for the BMD system represents a 
significant change of scale from what has 
been attempted so far, potentially involv¬ 
ing several hundred agents. It is likely that 
the answers to questions about coordina¬ 
tion and communication in systems that 
large will be different from what has been 
learned about smaller systems. 

SDI expert systems should have appli¬ 
cability in permitting large-scale distrib¬ 
uted problem-solving architectures to be 
implemented and tested. They also might 
be developed and used for dealing with a 
variety of anomalies—inconsistency, un¬ 
certainty, partial information—in the 
BMD context. 

Developing expert systems for the SDI 
environment is not an easy task. In fact, 
some of the problems associated with de¬ 
veloping these expert systems deserve ex¬ 
amination. 


Problems with 
developing expert 
systems for SDI 
applications 

There are several difficulties in design¬ 
ing expert systems for the SDI environ¬ 
ment. One important area is that the 
expert system must be “evolvable.” Since 
new technologies and SDI-related require¬ 
ments will be discovered over the next 15 
years, the expert system must be able to 
easily handle the integration of this new 
knowledge into the old. Thus, a very 
modular approach to designing the knowl¬ 
edge base is needed, along with a fairly 
easy semiautomated (or fully automated) 
way of acquiring knowledge and inte¬ 
grating it into the knowledge base. A way 
of checking for consistency of infor¬ 
mation and possible conflicts of existing 
and new requirements must be incorpo- 
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rated into the expert system. Reliability of 
a SDI expert system is also a major 
concern, as expressed in Parnas’ works. 30 

Another area of difficulty lies in devel¬ 
oping expert systems where there may be 
“no experts” who exist as of the time of 
building the expert system. Experts may 
exist for developing parts of the knowl¬ 
edge base; however, the knowledge base 
may have to contain knowledge in which 
there are no experts that currently exist. 
For example, the effects of chemical lasers 
or neutral-particle beams on certain 
objects are areas that are not known now 
since these weapons haven’t been built, 
tested, and used against ballistic missiles. 
Thus, at the present time, the knowledge 
base may not be able to include such 
information, but as time evolves, this 
information may be obtained and en¬ 
coded. This suggests that current expert 
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BOOK REVIEWS 


Applied Concepts in Microcomputer 
Graphics— Bruce A. Artwick (Prentice- 
Hall, Inc., Englewood Cliffs, N.J., 

1984, 374 pp„ $27.95) 

The stated aim of this book is to 
cover in one volume enough practical in¬ 
formation for someone to work with 
and to design computer graphics sys¬ 
tems, particularly those systems involv¬ 
ing microcomputers. There are chapters 
on hardware, peripherals, software tech¬ 
niques, transforms, and applications. 
There are appendixes on the Apple and 
the IBM personal computers. 

The book attempts both to be an in¬ 
troduction and to go into depth—to be 
self-contained. It is aimed at the well 
motivated reader who has some mathe¬ 
matical but no computer training. In 
this, it succeeds well. It goes into much 
greater depth than the general run of 
microcomputer graphics books, and ap¬ 
proaches the level of computer graphics 
textbooks. It does not quite reach this 
level because of a number of omissions. 

The major omission is references. One 
might argue that these can be obtained 
from other sources, but in a book that 
aims to be self-contained, it is a prob¬ 
lem. Some specific topics omitted are 
inkjet and wax transfer plotters, 
graphics standards (neither GKS nor 
Core are mentioned), and the use of 
icons. 

There are only cursory descriptions of 
hidden line and surface techniques, and 
the use of splines. The style of the 
writing is somewhat condescending, in¬ 
volving frequent use of the second 
person. 

There are a number of misprints, in¬ 
cluding 

p. 198, Fig. 7.1 (b) line 80 for “ + B” 
read “*B” 

p. 273, after “circle 
area = pi x radius” add “squared” 


p. 281, for “C d ” read “D c ” 
p. 290, for “ns” read “mS” 
p. 324, for “by” read “y b ” 

The book does cover some areas well 
that are poorly covered even in good 
texts. In particular, the descriptions of 
the video signal, raster graphics pro¬ 
cessors, CRT phosphors, and the use of 
quaternions are excellent. 

These positive points are good enough 
to make the book a reference work in 
tertiary computer graphics courses. 

Don Herbison-Evans 
University of Sydney 


Quantitative System Performance— 

E. D. Lazowska, J. Zahorjan, G. S. 
Graham, and K. C. Sevcik (Prentice- 
Hall, Englewood Cliffs, N. J., 1984, 417 
PP-, $35) 

As stated by the authors, the main ob¬ 
jective of this book is to assist computer 
system performance analysts in using the 
queueing network modeling technology 
for answering questions about cost and 
performance of computer systems. 

The book is divided into six parts. 

Part I contains background material on 
queueing network, or QN, based models 
of computer systems, modeling method¬ 
ology, and fundamental relationships 
between various performance parame¬ 
ters. Part II concentrates on solution 
techniques, with chapters on such sub¬ 
jects as finding bounds on overall sys¬ 
tems performance (i.e., system through¬ 
put and response time), solutions of 
single and multiple chain QN models, 
and flow equivalent aggregation of sub¬ 
networks. The portion on model solu¬ 
tion techniques considers open, closed, 
and mixed networks; however, only the 


Mean Value Analysis, or MVA, tech¬ 
nique is discussed there, and, in fact, in 
the rest of the book. Both exact and ap¬ 
proximate MVA schemes have been de¬ 
veloped using operational arguments. 

Part III deals with approximate mod¬ 
eling of several special features of com¬ 
puter systems such as memory limita¬ 
tion, swapping, paging, multiple disk 
drives served by a single channel, rota¬ 
tional position sensing, or RPS, on disk 
drives, scheduling disciplines not satisfy¬ 
ing the product form property, etc. Part 
IV examines the problem of calibrating 
and validating queueing network models 
of existing, evolving, and proposed com¬ 
puter systems. Part V considers extended 
applications of QN modeling (e.g., mod¬ 
eling of computer networks, database 
concurrency, software synchronization, 
etc.), and the design of a typical QN 
modeling based solution package. 

Part VI (the appendix) includes con¬ 
struction and calibration of the QN 
model of an IBM/MVS system using the 
data reported by the RMF utility; im¬ 
plementation of single- and multiple- 
chain exact MVA for networks with only 
load independent and delay stations; and 
MVA equations for the load-dependent 
case. 

My overall impression of the book is 
highly positive. The book is unique in 
addressing the practical issues in con¬ 
structing, calibrating, solving, and vali¬ 
dating simple models of real computer 
systems. In this respect, the book fulfills 
its objective of assisting performance 
analysts in constructing realistic and yet 
efficiently solvable analytical models of 
computer systems. Its major plus is that 
it can be effectively used by even those 
who do not want to delve into the theo¬ 
ry behind the solution techniques. I 
found it highly readable and well 
written. 

There are a few issues that need fur¬ 
ther elaboration in order to make the 
book more useful. It appears that the 
authors have gone somewhat overboard 
in trying to avoid the underlying theory. 
For example, there is no clear discussion 
of local balance, product form solutions, 
conditions required for product form 
solution, an MVA equation for a load 
dependent station, etc. Another problem 
with the book is that many of the ap¬ 
proximate solution techniques (e.g., 


Recently published books and new periodicals may be submitted for 
review to the book reviews editor: 

Francis P. Mathur, Mathematics Department, California State Polytechnic 
University, 3801 West Temple Avenue, Pomona, CA 91768, (714) 598-4421. 

Note: Publications reviewed in this section are not available from the 
IEEE Computer Society; they must be ordered directly from the publisher. 
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modeling of memory constraints or pro¬ 
cessor scheduling disciplines) are not 
presented with adequate information 
regarding the range of errors that one 
can expect or the situations under which 
the approximation might give unsatisfac¬ 
tory results. As an example, the heuristic 
expression for the response time equa¬ 
tion in the case of preemptive priority 
discipline is justified only on the basis of 
the response times at the preemptive pri¬ 
ority station for the higher priority chain 
in a two-chain network. (The results are, 
however, given for different values of 
populations in the higher priority chain.) 
The results happen to be almost the 
same as those reported by simulation. 
(Simulation results are reported through¬ 
out the book as sample means; no con¬ 
fidence intervals are available.) This may 
create the false impression regarding the 
accuracy of the approximation. How¬ 
ever, a closer look would reveal that the 
behavior of the highest priority chain is 
totally independent of the other chains 
(under preemptive priority scheduling); 
therefore, the MVA equation for it is ex¬ 
act and the accuracy would be expected 
to be good. Thus the accuracy should be 
judged from the results for the lower 
priority chains. Another point, of 
course, is that a single example proves 
nothing. It would be much more sub¬ 
stantive to give the range of errors 
experienced when the technique is used 
on a large number of examples. 

Despite the two weaknesses noted 
above, I believe that this book not only 
fills an important need but also has the 
potential of bringing QN based model¬ 
ing technology into wide use for evaluat¬ 
ing the performance of complex com¬ 
puter systems. I recommend it strongly. 

K. Kant 

The Pennsylvania State University 


Review of Micro Database Management: 
Practical Techniques for Application 
Development— R. H. Bonczek, C. W. 
Holsapple, and A. B. Whinston (Aca¬ 
demic Press, Orlando, Fla., 1984, 

$37.50) 

This book is a very well written text to 
accompany two pieces of software: 
MDBS III and Knowledgeman. The 
authors were responsible for providing 
the intellectual capital for these micro¬ 
computer database managers, and in this 
book they lead the reader through their 
approach to database management. 

The book begins by trying to examine 
various approaches to database in a 


dispassionate way. However, it rapidly 
becomes clear that the authors are not 
neutral at all. They like what they have 
done and believe it is the preferred way 
of creating databases for a micro. They 
do provide appendices that describe 
some mainframe-based database manag¬ 
ers such as ADABAS. After the initial 
chapters, they give up any pretense of 
writing a general book on database 
management for micros and spend their 
time telling the reader how their par¬ 
ticular database system works. They also 
include an appendix on relational data¬ 
bases in which they argue that many cur¬ 
rent notions about relational databases 
are incorrect myths. 

As a text to accompany their soft¬ 
ware, this book should work quite well. 
If you are using some other database 
manager, either professionally or as an 
instructor, the book would hinder rather 
than help you. Conversely, if you are 
looking for a good database manager 
that is supported by a good text, obtain¬ 
ing the book and the software makes 
sense. 

Paul Gray 

Claremont Graduate School 


Microcomputer Systems: The 8086/88 
Family Architecture, Programming and 
Design—Y u-Cheng Liu, Glenn A. Gib¬ 
son (Prentice-Hall, Englewood Cliffs, 
N.J., 1984, 550 pp„ $32.95) 

Given the relevance of the 8086 fami¬ 
ly, I welcome this well written book, 
which, besides presenting a processor- 
specific discussion, paints a very clear 
picture of the problems encountered in 
microcomputer system design and pro¬ 
gramming. In recent years there has 
been a plethora of books dealing with 
specific micros. Often these books offer 
little more than the original producer 
manuals, since they focus on the micros 
while missing major concepts in system 
design and programming. I must say 
that this is not the case with this book, 
where general concepts are presented in 
a well-structured manner. Take for in¬ 
stance the part dedicated to procedures. 
Calls, returns, and definitions are 
presented in terms of 8086 architecture 
and of 8086 assembler language, but the 
reader will grasp more general concepts, 
independent of the micro discussed. In 
that specific context, explanation of 
recursive procedure calls flows naturally. 

A distinctive aspect of 8086 architec¬ 
ture is memory segmentation. Memory 
segmentation makes addressing less easy 


to understand. Even more intricate are 
the consequences of memory segmenta¬ 
tion on assembler programming. Again, 
the authors are very successful in presen¬ 
ting assembly programming. (Please 
note that, as usual, most of the discus¬ 
sion on architectural characteristics is 
carried out by developing ASMB sample 
programs.) 

The format of the book is as follows. 
The first two chapters contain an in¬ 
troduction to and the basics of 8086 ar¬ 
chitecture. Chapter 3 presents assembler 
language programming. The succeeding 
three chapters are dedicated to program 
construction, string manipulation, and 
I/O programming. Chapter 7 gives some 
notions of multiprogramming and brief¬ 
ly describes the iRMX 86 real-time 
operating system and other issues related 
to memory management. 

Chapter 8 is dedicated to system bus 
structure, to the explanation of the two 
modes of operation (i.e., minimum and 
maximum modes), and to interrupt 
management. Chapter 9 discusses inter¬ 
facing and contains an in-depth descrip¬ 
tion of the most commonly used I/O 
devices and their use, including the 
8251A Programmable Communication 
Interface, 8255A Programmable Periph¬ 
eral Interface, 8254 Programmable In¬ 
terrupt Timer and DMA controllers, 
diskette controllers, and others. Chapter 
10 discusses semiconductor memories. 

Multiprocessing is discussed in Chap¬ 
ter 11, where the use of the 8087 and 
8089 is discussed as well. The last 
chapter discusses the 80186, the 80286, 
and the 80130, a device which is specifi¬ 
cally designed to support the iRMX 86 
operating system. 

The book has very few deficiencies. 
Certain descriptive parts could have been 
omitted; they are there to say that they 
exist, but add little to understanding. 

When describing the interrupt system, 
a scheme of a daisy-chain is presented 
that does not work. This daisy-chain is a 
purely switching (combinatorial) net¬ 
work; as such, it operates on signal 
levels rather than on signal edges. As a 
result, that daisy-chain is unable to catch 
the low-going edge of the \INTA signal: 
an error may result, with more than one 
device having its interrupt request 
acknowledged during an INTA cycle. 

My overall judgment is very positive. 
This is one of the best books I have ever 
read on microprocessors. I would 
recommend it to the reader who wants 
to know more about 8086 hardware and 
software architectures, but also to the 
reader who wants to understand micro¬ 
computer systems in general. 

Giacomo Bucci 
University of Florence 
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Tutorial: Computers for Artificial Intelligence Applications by Benjamin W. Wah and 
Guo-Jie Li 

Presents fundamentals in language-oriented and knowledge-oriented computer architectures for artificial intelli¬ 
gence applications. A guide for the beginner, as well as a major reference for all professionals in computer engi¬ 
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level architectures, Functional-programming-oriented architectures, Logic and knowledge oriented architectures, 
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Tutorial: Computer Text Recognition and Error Correction by Sargur N. Srihari 

Designed for computer researchers interested in developing flexible techniques for text processing and computer 
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automatically detect and correct spelling and typographical errors and to interpret digitized video images of print 
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List price $36.00/Member price $24.00 
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levels on a discrete lattice, volume One deals with processing oftmages. CONTENTS: ImageTffiiisfuilli?, Image 
Models, Image Data Compression, Image Enhancement, Image Restoration. 

Order No. DD665 (ISBN 0-8186-0665-7): June 1985,736 pp. 

Ust price $66.00/Member price $36.00 -f- 
Volume 2: Digital Imag e Analysis 

Concentrates on the analysis of images. CONTENTS: Feature Extraction and Boundary Analysis; Region Analysis; 
Image Sequence Analysis; Multiresolution Image Analysis. 

Order No. DD666 (ISBN 0-8186-0666-5): Dec. 1985,680 pp. 

List price $66.00/Member price $36.00 

Proceedings: Second International Conference on Artificial Intelligence Applications 

Explores the technology, implementation, and impact of emerging application areas and indicates future trends 
in available systems and required research. 

Order No. DD688 (ISBN 0-8186-0688-6): Dec. 1985,704 pp. 

List price $75.00/Member price $37.50 
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UPDATE 


Board of Governors approves slate of candidates Cragon wins Eckert- 

for fall election Mauchly award 


At its May 9 meeting in Miami, 
Florida, the Computer Society Board of 
Governors approved the following slate 
of candidates for 1987 officer and Board 
of Governors positions, to be filled by 
membership ballot this fall. 

President 
Roy Russo 
President Elect 
Taylor Booth 
Edward Parrish 
First Vice President 
James Aylor 
Michael Mulder 
Second Vice President 
Kenneth Anderson 
John Musa 
Board of Governors 
Tilak Agerwala 
Mario Barbacci 
Victor Basili 
Bruce Berra 
Wushow Chou 
Lorraine Duvall 
Michael Evangelist 
Wolfgang Giloi 
Allen Hankinson 
William Howden 
Barry Johnson 
Laurel Kaleda 
Ted Lewis 
Ming Liu 
Troy Nagle 
Gordon Padwick 
Roland Saam 
Earl Swartzlander 
Joseph Urban 

Additional nominees can be added to 
the ballot by membership petition (see 
Computer, January 1981, p. 108, for 
Computer Society bylaws requirements 
for petition candidates). Petition 
candidates must submit their petition 
signatures (250 voting members for 
officer nominees, 50 voting members for 
Board of Governors nominees) together 
with their biographical data and 
candidate statements, to the Computer 
Society secretary at the following address 
on or before August 4, 1986: 

Secretary 

Computer Society Elections 
IEEE Computer Society 
10662 Los Vaqueros Circle 
Los Alamitos, CA 90720 


Candidates’ statements and bio¬ 
graphical data will be published in the 
September 1986 issue of Computer 
magazine and will be included in the 
IEEE ballot mailing. Length limitations 
and format suggestions for these 
materials are as follows: 

Candidates ’ statements 


President 350 words 

President Elect 350 

Vice President 250 

Board of Governors 150 

Biographical data 
All candidates 200 


Biographical sketches should cover the 
following topics in the sequence sug¬ 
gested below: 

• IEEE-CS activities 

• Other professional activities 

• Current employment and position, 
professional experience, and 
accomplishments 

• Degree(s) and major(s) 

• Awards and honors 

Nominees should also submit a black- 
and-white passport-type photograph of 
themselves for publication along with 
their statements and biographies. 


Bernard M. Oliver, chief of the Search 
for Extraterrestrial Intelligence (SETI) 
program at NASA-Ames Research Cen¬ 
ter, has received the National Medal of 
Science for his work in the field of con¬ 
sumer electronics. 

A long-time executive at the Hewlett- 
Packard Company, Oliver developed the 
first hand-held calculator with scientific 
functions, which sold in 1972 for $395. 
He retired in 1983 from Hewlett-Packard 


Maxell Corporation has developed a 
2- Vi -inch floppy disk that holds 500K 
bytes of unformatted storage, the same 
capacity as today’s conventional 
5-14-inch floppies. 

The magnetic material used on the 
floppy is an ultra-fine epitaxial powder, 


Harvey G. Cragon of the University of 
Texas at Austin has received the 1986 
Eckert-Mauchly Award, conferred joint¬ 
ly by the IEEE Computer Society and 
the Association for Computer 
Machinery. 

Presented annually since 1979, the 
Eckert-Mauchly Award honors technical 
contributions to computer and digital 
systems architecture. Cragon was cited 
for major contributions to this field, 
especially for work performed during 25 
years of service at Texas Instruments, 

Inc. Cragon designed and constructed 
the first integrated-circuit computer and 
the first TTL computer. He worked on 
the design of the TI advanced scientific 
computer and served as principal ar¬ 
chitect of the TMS 320 signal processing 
microcomputer. 

Cragon is a member of the IEEE 
Computer Society, the ACM, the IEEE, 
the National Academy of Engineering, 
and the Charles Babbage Institute. In 
1984 he received the IEEE Emanuel R. 
Piore Award. 

Cragon received the award, which car¬ 
ries a stipend of $1000, at the 1986 Com¬ 
puter Architecture Symposium held June 
3-5 in Tokyo, Japan. 


to head the SETI program office. With 
antennas used for radio astronomy and 
for the Jet Propulsion Laboratory’s 
Deep Space Network, the SETI program 
searches for radio signals that could be 
interpreted as signals transmitted by in¬ 
telligent extraterrestrial beings. 

Oliver authored the article, “Signal 
Processing in SETI,” which appeared in 
the November 1985 issue of Computer. 


providing the disks with a magnetic rat¬ 
ing of 650 oersteds. The floppies have a 
maximum recording density of 9.4K with 
40 tracks per side. 

For more information, contact Maxell 
Corporation, 60 Oxford Drive, Moon- 
hachie, NJ 07074; (201) 641-8600. 


Author wins National Medal of Science 


Company develops 2-V2-inch floppy disk 
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Tl to deliver Lisp chip with 550K transistors 



This scanning electron micrograph of two trench-transistor storage cells from a Texas 
Instruments 4-Mbit DRAM illustrates the three-dimensional integration found in the 
DARPA Compact Lisp Machine. Individual cell size is 8.9 square microns. 


by Richard Landry 
Managing Editor 

After about two years of development, 
engineers at Texas Instruments’ semi¬ 
conductor facilities in Dallas, Texas are 
preparing to deliver to the Defense 
Advance Research Projects Agency a 
prototype version of its Compact Lisp 
Machine, a high-density, 32-bit chip that 
holds more than 550,000 transistors and 
runs at speeds of up to 40 MHz. 

The CLM, a miniaturized version of 
TI’s Explorer Lisp processor, is part of 
an apparent company strategy to drive 
the scale of high-performance symbolic 
computing down to the desktop and 
even the portable level. According to TI 
representatives, in the military environ¬ 
ment the CLM is meant to function as a 
“Lisp machine in a shoe box,” for 
embedded applications such as pilot 
assistance and robotic vehicular control. 
TI is also working on a commercial 
version of the CLM, dubbed the 
Explorer MegaChip, for applications 
such as industrial control. 

The CLM is actually a four-chip set, 
built around the one-centimeter-square 
CPU. The set also includes a combi¬ 
nation data cache and memory mapper, 
a 2 Mbit DRAM, and a Multibus 
interface module. The processor and 
memory are implemented in high-density 
CMOS using double-level metal 
interconnect technology. 

DRAM technology drives advances. 

According to Gregory J. Armstrong, 
associate director of TI’s semiconductor 
design center in Dallas, the groundwork 
for the high level of integration exhibited 
in the CLM was laid in work to achieve 
increasingly dense memories, first in 
1-Mbit CMOS DRAMs and later in the 
4-Mbit DRAM, which combines bipolar 
double-metal technology with CMOS 
technology. Because the low cost of 
DRAMs makes manufacturing efficiency 
particularly important, Armstrong said, 
work in this area encourages the 
commercial production of units that 
combine logic and a large memory onto 
a single chip. Because this architecture 
eliminates chip-to-chip interconnect, 
such single-chip systems exhibit what 
Armstrong called “inherent reliability,” 
making them particularly suited to 
mission-critical applications. According 
to Mike Watson of TI’s Symbolic 
Computing Laboratory in Dallas, work 
in the company’s DRAM program is also 
proceeding on radiation hardening for 
CMOS components. 

Circuit-packing imitates brain. To 
achieve these high circuit densities, TI 


scientists turned to a form of three- 
dimensional integration which packs en¬ 
tire memory cells vertically into trenches 
descending from the chip’s surface. This 
structure, Armstrong said, is roughly 
analogous to that found in the folds of 
the cerebral cortex, which increases the 
surface area and thereby the higher level 
functions of the brain. Such integration 
is essential to the 4-Mbit DRAM, which 
must hold approximately 8.4 million 
components, including capacitors. 
Single-chip systems would operate at 
lower densities however, Armstrong said, 
since logic tends to be semi-random 
whereas memory is highly symmetrical 
and therefore capable of being tightly 
packed. 


An independent laboratory to test 
computer software products to ensure 
that they are usable by their intended au¬ 
dience has opened in Washington, DC. 

Part of the American Insititutes of Re¬ 
search (AIR), the Usability Test Labora¬ 
tory tests prototype software and man¬ 
uals by analyzing the behavior of typical 
users as they work with the product in a 
controlled environment. AIR psycholo¬ 
gists measure behavior such as the num¬ 
ber of help requests, time taken to ac- 


TI representatives state that, although 
the CLM has been designed to be deliv¬ 
ered in fully sealed ceramic circuit boards 
that fit into a 6Vi x6% inch housing, the 
first shipments will be made in the tradi¬ 
tional Explorer chassis. The CLM will 
run a superset of Common Lisp that is 
compatible with the larger Explorer sys¬ 
tem for software development purposes. 
Interactive software development and 
debugging aids are also on the drawing 
board. 


The Texas Instruments Compact Lisp 
Machine was the topic of a briefing held 
April 30 at AI ’86 in Anaheim, 
California. 


complish tasks, and number of errors 
committed. 

The test laboratory also conducts com¬ 
parative studies to determine which of 
two proposed alternatives that a manu¬ 
facturer is considering would work bet- 

AIR is an independent nonprofit com¬ 
pany. In addition to its Washington of¬ 
fices, it runs research centers located in 
Palo Alto, California, and Cambridge, 
Massachusetts. 


Lab tests computer products for usability 
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Advance Registration 

/nnci a ’86 


ACM Conference on Object-Oriented Programming 
Systems, Languages, and Applications 
Portland Marriott, Portland, Oregon 


Tutorial Sessions: September 29 


Welcome Keynote Speaker: Kristen Nygaard 


Conference: September 30 - October 2, 1986 

00PSLA-86 brings together users and implementors of 
object-oriented systems through tutorials, papers, 
panel discussions and poster sessions, as well as 
exhibits, demonstrations and videotapes. 00PSLA-86 
will provide a forum for sharing experience and 
knowledge among experts and novices alike. 

Fifty refereed papers present advances in: Languages, 
Systems and Implementations, Applications, Theory, 
Databases, Application Frameworks, and Tools. 

Six panels of experts will explore important topics: 
Teaching OOP, OOP for Product Development, The 
Future of OOP, OOP Without an 00 Language, 
Architectural Support for OO Programming, and OO 
Application Frameworks. 

OOPSLA-86 is the first ACM conference to assemble 
the various branches of object-oriented programming. 
Space is limited. Register early. 

Tutorials 


Part I: Introduction to Object-Oriented Programming 

Introduction to Object-Oriented Concepts 
Survey of Object-Oriented Programming Systems 
Introduction to the Smalltalk-80 System 
Object-Oriented Application Frameworks 


Part II: Introduction to Specific Object-Oriented Systems 


1 C++ 

2 CommonLoops 

3 Flavors 

4 Methods 

5 Neon 

6 Objective-C 

7 Object Pascal 


J. Shopiro Bell Labs 

D. Bobrow & G. Kiczales Xerox 
D. Weinreb Symbolics 

G. Bosworth Digitalk 

C. Noe Kriya Systems 

B. Lockwood PPI 

S. Wallace & L. Rosenstein Apple 


Banquet Keynote Speaker: Alan Kay 

The banquet at 7:30 pm, Wed., Oct. 1 is included in the 
conference fee. Extra tickets are $30 ea. 

Boat Excursion 

Pre-banquet riverboat reception/cruise on the Willamette 
River is included in conference fee. Extra tickets $10 ea. 

Hotel and Travel Reservations 

OOPSLA-86 rates at the Portland Marriott are $66/day 
(single or double), $10 for each additional person. Call 
(503) 226-7600 for reservations. Please reserve early. 
Special conference airline discount rates are available from 
United Airlines: call (800) 521-4041, account #6136A. 


For the complete advance program write to: 
OOPSLA-86, PO Box 3845, Portland, OR 97208-3845 


Advance Registration 

(received by Aug. 21) 



Conference 

Tutorial 

ACM member 

□ $155 

□ $200 

non-member 

□ 195 

□ 240 

full time student 

□ 50 

□ 100 

Late Registration (received after Aug. 21) 


ACM member 

□ $215 

□ $250 

non-member 

□ 255 

□ 290 

full time student 

□ 50 



Conference fee includes banquet, proceedings, and boat excursion. 
Tutorial fee does not include conference. Requests for refunds 
will be honored until Sept. 15, 1986. 


_ additional banquet tickets @ $30 each 

_ additional boat excursion tickets @ $10 each 

Name _ 

Title _ 


The part II sessions will be presented in parallel. Each 
of them will be presented twice so that you can attend 
your choice of two of these tutorials. Please mark your 
preference on the registration form to the right to aid 
in the scheduling of rooms. You may change your 
selection at the time of the tutorials. 

Exhibits 

The exhibit hall will offer displays and demonstrations 
by both software and hardware vendors of object-oriented 
systems. 


Organization 
Address _ 


Registration fees enclosed total $ _ (US dollars) 

Make checks payable to: OOPSLA-86 
Send to: PO Box 3845 

Portland, Oregon 97208-3845 

Part II Tutorials (Please circle choice of two if attending tutorials) 
1 2 3 4 5 6 7 














NEW PRODUCTS 


Editor: Demetrios Michalopoulos/California State University, Fullerton 


Special Feature 


Al programs permit development of expert systems on PCs 


Compiled by Nancy Hays, Assistant Editor 

Artificial intelligence programs nor¬ 
mally take a great deal of memory, more 
memory than is available on any small 
system. However, because of the huge 
success of the personal computer, com¬ 
panies that market artificial intelligence 
programs have had great incentive to 
create systems that run on PCs. During 
the last few years such programs have 
entered the marketplace in growing 
numbers. 

Most of the artificial intelligence prod¬ 
ucts for personal computers are develop¬ 
ment systems, often converted into C 
from a mainframe version written in 
Lisp or Prolog. In effect, they provide 
toolkits to help the PC owner build a 
custom-made application specific to the 
problem at hand, whether it is analyzing 
echocardiograms or fault-checking a 
boiler system. 

The expert-system applications 
covered here include programs that 
incorporate AI concepts, such as 
AI:Typist, a word processor, as well as 
specific applications created with an 
already-existing AI development system, 
such as Cocomo 1, a software costing 
assistant for large software development 
projects, based on Insight 2 +. A rare 
handful combine development tools with 
an application, such as Guru, which 
combines an expert system development 
environment with business tools. 

This special section samples develop¬ 
ment systems and applications. The 
discussion of each program is necessarily 
brief, with a summation of basic points 
for many of them in the accompanying 
table. Company addresses and telephone 
numbers are included for those wishing 
more information on any of the 
products. 


Development systems and 
applications 

Teknowledge Inc. offers two different 
programs for expert system develop¬ 
ment, M.l and S.l. M.l runs on the 


IBM PC, PC-XT, PC-AT, and compat¬ 
ibles. It handles small to medium sys¬ 
tems, of up to 1000 or so rules. S.l runs 
on the IBM RT-PC and handles large 
system development, with large numbers 
of knowledge base entries. A completely 
different program with a different design 
strategy than M.l, it offers more fea¬ 
tures and makes possible more complex 
applications. A delivery version of S.l is 
available for the IBM PC-AT for $3,000, 
but it requires a packager that costs 
$9500. The company plans to market a 
development system for the PC-AT by 
the end of 1986. A Quick Start package 
for $7500 bundles M.l with two training 
courses, maintenance, and licensing for 
delivery versions of the buyer’s expert 
system. 

Level Five Research offers two devel¬ 
opment systems, Insight 2+ and Insight 
1 +, and an application developed under 
Insight 2 +, Cocomo 1. Insight 2 + sup¬ 
ports linked knowledge bases, math 
functions, and external programs and 
devices. Insight 1 + shows how to build 
expert systems, employing extensive 
tutorials. Users must stay inside the shell 
with Insight 1 +, which has no run-only 
version. It is scheduled for August. Co¬ 
como 1 estimates the manpower, costs, 
and time requirements for software 
projects. It implements the mathematical 
constructive cost model developed by 
Barry Boehm of TRW for software 
costing. 

Neuron Data Corp. developed 
Nexpert for the 512K Macintosh and 
Macintosh Plus. It handles up to 500 
rules with forward, backward, and 
mixed chaining. The knowledge editor 
consists of the rule editor, category 
editor, and text editor. Windows in the 
knowledge base list data, hypotheses, 
rules, and categories. The user can 
override default settings of the inference 
engine, classify and set priorities for data 
by category, link graphics or text to data, 
print or save reports, and ask the pro¬ 
gram to justify its conclusions. Nexpert 
accepts SYLK format files, so can use 
data imported from Microsoft’s Excel 
spreadsheets. 


RuleMaster from Radian automatical¬ 
ly generates rules from case examples 
and writes the rules in a rule language 
called Radial. It expresses the rules as a 
hierarchy of decision trees. Thus it has 
no single, large rule base and separate 
inference engine. Instead, the small rule 
sets of the hierarchy are connected by 
traditional structured language methods. 
This development system can generate a 
compilable C code representation of the 
expert system, which allows users to 
embed their applications within other 
programs. The PC version of RuleMast¬ 
er requires a C compiler. 

A combination of expert system devel¬ 
opment environment and business tools, 
Guru from Micro Data Base Systems 
(mdbs) functions as a rule set manager 
and inference engine. It adds AI con¬ 
cepts to the company’s Knowledge 
Man/2 database management system. 
Business tools in the program include a 
spreadsheet, database managment, 
remote communications, graphics, and 
word processing. The system employs 
both forward and backward chaining. It 
supports three networks: IBM PC, 

Novell Netware, and 3Com Ethernet. 

KESII from Software Architecture 
and Engineering is based on that com¬ 
pany’s KES (Knowledge Engineering 
System) program, which is a domain- 
independent support tool for building 
expert systems. KES II expands the 
capabilities offered by KES. Imple¬ 
mented in C, KES II can be integrated 
with existing applications. 

Human Edge Software offers Expert 
Edge, a development system, and Fore¬ 
casting Edge, a business forecaster. Ex¬ 
pert Edge uses a deductive reasoning in¬ 
ference engine. Data entry takes place 
through a natural language interface or 
through an interface to databases, 
spreadsheets, and word processors. The 
program uses a balance of probabilities 
and Bayesian statistics to handle uncer¬ 
tainties and incomplete information. It 
justifies the reasoning for any advice 
given and permits the expert to include 
context-sensitive help text in the applica¬ 
tion program. Forecasting Edge employs 
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Product 

Hardware 

requirements 

Language 

Operating 

system 

Mainframe 

version? 

Function 

Price 

R.S. 

No. Company 

M.1 

IBM PC, PC-XT, 

PC-AT, and compatibles; 
512K bytes 

C 

MS-DOS, PC-DOS 

Planned 

Development 

$5000 

30 Teknowledge Inc. 

1850 Embarcadero Rd. 

PO Box 10119 

S.1 

IBM RT-PC; 2M bytes 

C 

MS-DOS 

Planned 

Development 
and delivery 

$25,000 | 

31 Palo Alto, CA 94303 
| (415) 424-0500 

Insight 2 + 

IBM PC, PC-XT, PC-AT, 
and compatibles; 512K 
bytes, hard disk 
recommended 

Compiled 
Turbo Pascal 

MS-DOS or PC-DOS 
v. 2.0 or higher 

Planned 

Development 

$485; $95 
for run-only j 

32 Level Five Research, Inc. 

503 Fifth Ave. 

Indialantic, FL 32903 
(305) 729-9046 

Insight 1 + 

IBM PC, PC-XT, PC-AT, 
and compatibles; 340K 
bytes 

IBM PC, PC-XT, PC-AT, 
and compatibles; 340K 
bytes, 2 drives 

Turbo Pascal 

MS-DOS or PC-DOS 
v. 2.0 or higher 

No 

Development 

$95 

33 

Cocomo 1 

Turbo Pascal 

MS-DOS or PC-DOS 
v. 2.0 or higher 

No 

Software 

costing 

assistant 

$100 

34 

Nexpert 

Macintosh Plus or 
512K-byte Macintosh 

Assembly 


No 

Development 

$5000; 
$1000 for j 
runtime 
only 

35 Neuron Data Corp. 

444 High St. 

Palo Alto, CA 94301 

H (415) 321-4488 

RuleMaster 

IBM PC-XT, PC-AT, and 
compatibles; 640K 
bytes, hard disk 

C 

DOS 

Yes 

Development 

$995 

36 Radian Corp. 

8501 Mo-Pac Blvd. 

PO Box 9948 

1 Austin, TX 78766 

Mil (512) 454-4797 

Guru 

IBM PC and 
compatibles; 512K 
bytes, hard disk 

C 

PC-DOS, MS-DOS 

Yes 

Database 

management 

system 

$2995; 

$300 for 
runtime 
only 

37 Micro Data Base Systems 

V* (mdbs), Inc. 

PO Box 248 

Lafayette, IN 47902 
«(317) 463-2581 

KES II 

IBM PC-AT, PC-XT, and 
compatibles; 640K bytes 

C 

MS-DOS 

Yes 

Development 

$4000 

38 Software Architecture and 
Engineering, Inc. 

1600 Wilson Blvd. 

Arlington, VA 22209 
■ (703) 276-7910 

Expert Edge 

IBM PC and 

compatibles; 256K bytes 
(512K bytes 

recommended), 2 drives 

C 

PC-DOS or MS-DOS 
v. 2.0 or higher 

No 

Development 

$795 

39 Human Edge Software 

1 Corp. 

, 1875 S. Grant St. 

San Mateo, CA 

Forecasting 

Edge 

IBM PC and 

compatibles; 256K bytes 

Pascal 

PC-DOS or MS-DOS 
v. 2.0 or higher 

No 

Business 

forecaster 

$99.95 

40 94402-2669 

(415) 573-1593 

KDS 

IBM PC, PC-AT, PC-XT, 
and compatibles; 512K 
bytes (320K bytes for 
runtime), 2 drives 
recommended 

Assembly 

PC-DOS 

No 

Development 

$795; 

$495 for 
playback 
module; 
$150 for 
playback 
utility 

41 KDS Corp. 

934 Hunter Rd. 

Wilmette, IL 60091 
(312) 251-2621 

Airus-A 

IBM PC and 
compatibles; 

256K bytes 

Lattice C, 
Microsoft C 

MS-DOS v. 2.0 or 
higher 

No 

Programmer's 

tool 

$150 

42 Airus, Inc. 

10200 S.W. Nimbus Ave., 

Y' ; Suite G-5 

AI:Typlst 

IBM PC and 
compatibles; 

256K bytes 

C 

MS-DOS v. 2.0 or 
higher 

No 

Word 

processing 

$99.95 

43 Portland, OR 97223 
(503)620-7000 
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the Box-Jenkins method to help users 
construct business forecasts without 
knowing forecasting or statistics. 

KDS from KDS Corp. provides a 
development system that produces a 
knowledge module. Users can chain 
together modules to make larger systems. 
The system supports both forward and 
backward chaining. It can execute exter¬ 
nal programs and accept data from 
them. A playback module is required to 
play back knowledge modules produced 
by any KDS development system ($495). 
A playback utility ($150) plays back only 
systems developed on the KDS devel¬ 
opment system to which it belongs. 

Airus has developed two products that 
use intuitive processing. Airus-A is both 
a technology and a programmer’s tool. 
Written in C, it consists of an artificial 
intelligence algorithm that accesses an in¬ 
telligent linguistic database. It compares 
input words with a dictionary and re¬ 
turns an attribute for processing. At¬ 
tributes assigned to tokens can return a 
code, a table index, or a full address 
pointer. The company applied Airus-A in 
constructing AI:Typist, a word process¬ 
ing program with a real-time spell check¬ 
er. The program saves documents either 
formatted or as ASCII files. 


Of further interest 

IntelliCorp offers KEE PC-Host, 

which delivers expert systems developed 


Toshiba adds portable PC 

Toshiba’s Information Systems 
Division has added the T3100 portable 
personal computer to its portable PC 
line. According to the company, the 

15- pound T3100 is completely IBM 
compatible. It comes equipped with a 

16- bit 80286 processor running at 8 MHz 
clock speed. 

The T3100 features 640K bytes of 
RAM and two drives, a 720K-byte 
3.5-inch disk drive and a lOM-byte hard 
disk drive. An internal lM-byte memory 
expansion board is optional, as is an 
external 5.25-inch 360K-byte disk drive. 

The portable comes with a gas plasma 
screen with 80-by-25-character display 
and 640-by-400-pixel resolution. It is 
software compatible with the IBM Color 
Graphics Adapter. Built-in interfaces 
allow for an RGB color monitor, parallel 
printer, RS-232-C asynchronous serial 
port, and external disk drive. An internal 


with the company’s Knowledge Engi¬ 
neering Environment (KEE) software on 
Lisp machines to personal computers. 
The PCs run an implementation of 
KEE’s interface while the host VAX runs 
a Common Lisp implementation of the 
expert system application. KEE’s graphic 
interface facilities are implemented in C 
and Digital Research’s GEM software to 
run on IBM PCs or compatibles with 
512K bytes, a serial port, and two disk 
drives, running MS-DOS 2.0 or greater. 
PC and host may be linked locally 
through a standard serial connection or 
remotely through a telephone modem. 
KEE PC-Host costs $27,500 on the host 
machine, including software license, five 
days of consultation, and a year of sup¬ 
port. The software alone costs $15,000, 
while a license for the software costs 
$500 per PC. For more information, 
contact IntelliCorp, 1975 El Camino 
Real W„ Mountain View, CA 94040; 

(415) 965-5500. Reader Service Number 44. 


Gold Hill Computers markets Golden 
Common Lisp (GCLisp) and supporting 
products for personal computers. Ac¬ 
cording to the company, GCLisp is 
training and development software for 
Common Lisp and AI programming. It 
runs on an IBM PC, PC-XT, PC-AT, or 
compatible computer with 512K bytes; a 
360K-byte, double-sided, double-density 
disk drive; and PC-DOS or MS-DOS, 
version 2.0 or higher. A hard disk or sec¬ 
ond floppy disk drive are recommended, 


expansion slot accommodates an op¬ 
tional 300/1200 bit-per-second Hayes- 
compatible modem card or an expansion 
chassis with five IBM-compatible slots. 

The T3100 sells for $4499. It comes 
with MS-DOS 2.11, GW-Basic, a power 
cord, a carrying case, and documen¬ 
tation. Like the T1100, it is backed by 
Toshiba’s Exceptional Care Program, 
which according to the company 
provides overnight replacement of a 
failed unit. 

Other options include an external 
15-key numeric keypad and a PC Floppy 
Link to allow use of a PC or PC-XT 
5.25-inch drive. 

For more information, contact 
Toshiba America Inc., Information 
Systems Division, 2441 Michelle Dr., 
Tustin, CA 92680; (714) 730-5000. 


Reader Service Number 48 


as are a floating-point processor and a 
printer. The language costs $495. Reader 
Service Number 45. 


The GCLisp 286 Developer, a more 
powerful version of GCLisp, is an AI de¬ 
velopment system for IBM PC-ATs and 
compatibles. It includes a memory inter¬ 
preter and compiler, editor, tutorial, and 
on-line help. The product requires at 
least 2M bytes of memory, PC-DOS 3.0 
or higher, a hard disk, and a DSDD or 
quad-density disk drive. The company 
recommends an IBM PC-AT with at 
least 3M bytes of memory, a Mouse Sys¬ 
tems mouse, and an enhanced graphics 
adaptor and color monitor. The GCLisp 
286 Developer lists for $1195. Current 
customers pay $895. Reader Service 
Number 46. 


GCLRun creates runtime versions of 
GCLisp applications. This delivery 
vehicle allows developers to create 
executable files from their compiled 
GCLisp programs to deliver stand-alone 
applications. GCLRun includes a foreign 
language interface that permits integra¬ 
tion of programs written in other lan¬ 
guages into GCLisp. The product ranges 
in price from $100 (5 to 99) to $5 (more 
than 50,000). Reader Service Number 47. 

For more information, contact Gold 
Hill Computers, Inc., 163 Harvard 
Street, Cambridge, MA 02139; (617) 
492-2071. 



Toshiba’s IBM-AT-compatible T3100 por¬ 
table PC features an 80286 processor. 
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Personal supercomputer from Culler 


Culler Scientific Systems Corp. has 
announced the Culler PSC personal 
supercomputer. According to the com¬ 
pany, the machine achieves 3 to 4 Mflops 
on the double-precision Linpack bench¬ 
mark. 

The Culler PSC interfaces with 
Ethernet-based LANs. It offers VMS- 
compatible Fortran and C compilers and 
a common back-end code generator 
suited for parallel architecture. It sup¬ 
ports one or two user processors, with 
up to 16M bytes in each bay and up to 
48M bytes with an additional memory 
module. 

According to the company, the Culler 
PSC offers four levels of parallelism. 
First, the operating system is executed on 


the kernel processor while user programs 
are executed on the user processor. Sec¬ 
ond, two identical user processors can 
execute simultaneously under the super¬ 
vision of a single kernel processor. Third, 
there are three parallel machines in each 
user processor, one controlling instruc¬ 
tion flow and two computational ma¬ 
chines. Fourth, each computational 
machine contains parallel function-level 
computing elements. 

The Culler PSC costs $98,500. For 
more information, contact Culler Scien¬ 
tific Systems Corp., 100 Burns Place, 
Santa Barbara, CA 93117; (805) 

683-5631. 

Reader Service Number 49 


TeleGen2 fosters development of Ada systems 


TeleSoft has announced its second- 
generation Ada development system, 
TeleGen2, for DEC VAX systems under 
the VMS operating system. It targets 
both the VAX/VMS and MC680X0 
systems. 

TeleGen2 is designed and written in 
Ada. It includes TeleSoft’s second- 
generation Ada compiler and a library 
manager, a library toolset, and an Ada 


execution environment. According to the 
company, all TeleGen2 products comply 
fully with Department of Defense 
ANSI/Mil-Std-1815 A specifications. 

Prices depend upon the tools ordered 
and the target systems. Contact TeleSoft, 
10639 Roselle St., San Diego, CA 
92121-1506; (619) 457-2700. 

Reader Service Number 50 



The Culler PSC personal supercomputer. 


Intel's iPSC-VX performs vector processing 


Intel Corp. has announced the iPSC- 
VX series of vector concurrent 
supercomputers, which are vector 
processing versions of its iPSC family of 
concurrent computers. 

The iPSC-VX series comes in three 
upgradable models. The iPSC-VX/d4 
has 16 vector computing nodes and 24M 
bytes of distributed memory. The iPSC- 
VX/d5 comes with 32 nodes and 48M 
bytes of memory. The iPSC-VX/d6 
consists of 64 nodes and 96M bytes of 
memory. 

According to the company, within the 
backplane of each iPSC computational 
unit, adjacent even and odd card slots 
are connected by the Multibus II iLBX 
bus, boosting each node’s floating-point 
performance. The iPSC vector board is 
organized around three functional units: 
a floating-point arithmetic unit, a data 
unit, and a control unit. The arithmetic 
unit is a pipelined processor composed of 
an adder and a multiplier, each capable 
of IEEE-754 standard floating-point 
operations. The data unit contains 1M 
byte of data RAM mapped into the 
address space of the node processor. 


The vector processor’s control code is 
loaded directly from the node processor 
and contains a library of vector, scalar, 
and logical operations. The vector pro¬ 
cessor board reputedly reaches a peak 
performance level of 6.67 Mflops (64-bit) 
and 20 Mflops (32-bit). 

The iPSC-VX/d4 will cost $250,000; 
the iPSC-VX/d5, $450,000; and the 


Intel Corp. and Gold Hill Computers 
jointly announced Concurrent Common 
Lisp (CCLisp) for Intel’s iPSC family of 
concurrent computers. CCLisp provides 
a Common Lisp environment on each 
node with message-passing constructs to 
support communication between nodes. 
CCLisp also provides debugging tools, a 
display interface to each node, and 
network services to Lisp workstations. 

Prices for the iPSC with CCLisp are 
$175,700 for the 16-node iPSC-MX/d4 
system; $305,700 for the 32-node iPSC- 
MX/d5 system; and $555,700 for the 
64-node iPSC-MX/d6 system. 


iPSC-VX/d6, $850,000. Additionally, 
the iPSC family can be upgraded to the 
iPSC-VX series. For more information, 
contact Intel Scientific Computers, 
Customer Response Dept., 15201 N.W. 
Greenbrier Parkway, Beaverton, OR 
97006; (503) 629-7629. 

Reader Service Number 51 


Intel and Gold Hill will jointly market 
CCLisp. Gold Hill will provide CCLisp 
software support and training. Intel 
provides service, support, and training 
for the iPSC family of concurrent 
computers. 

For more information, contact Intel 
Scientific Computers, Customer 
Response Dept., 15200 N.W. Greenbrier 
Parkway, Beaverton, OR 97006; (503) 
629-7629, or Gold Hill Computers, 163 
Harvard St., Cambridge, MA 02139; 

(617) 492-2071. 

Reader Service Number 52 


CCLisp runs on iPSC concurrent computers 
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Recent Microsystem Announcements 


For more information, circle the appropriate RS No. on the Reader Service Card at the back of the magazine. 


R.S. 

NO. 


MANUFACTURER 

AND MODEL FUNCTION COMMENTS 


Digital Vision, Inc., Video 
Computereyes acquisition 
system 


Definicon 
Systems, Inc., 
DSI-32 


32-bit 

coprocessor 

board 


Slow-scan video digitizer including software and video camera for capturing b/w 81 
images on the IBM Color Graphics Adapter of IBM PCs and compatibles. 

Software on disk includes machine language image capture routines, automatic 
calibration of brightness and contrast settings, menu-driven executive, and 
image save-to-disk capability. Hardware includes interface adapter, and a 
CCIR/PAL video with cable. Cost of complete system is $529.95; without video 
camera, $249.95. Digital Vision, Inc., 14 Oak St., Ste. 2, Needham, MA 02192; 

(617) 444-9040. 

A coprocessor board for IBM-compatibles whose major features include an 82 

NS32032 central processor (clocked at a minimum of 10 MHz), an NS32081 
floating-point processor, and an NS32082 memory management unit. The basic 
board has 2M bytes of dual-port RAM and its virtual memory system with 
demand paging provides 15M bytes of nonsegmented memory. The board 
supports multiuser tasks under the Unix V operating system and MS DOS. Cost: 
from $2295 depending on configuration. Definicon Systems, Inc., 31324 Via 
Colinas, Ste. 108, Wtestlake Village, CA 91362; (818) 889-1646. 


Microfield 
Graphics, Inc., 

T4 Color Graphics 
Controller 


Color graphics A 1024X 800,4-plane color controller equipped with a VLSI-based bit-slice 

controller processor for use with the RISC-based IBM RT PC. Supported by an ANSI CGI 

interface, it can be used either by the RT’s RISC processor or its optional DOS 
coprocessor. The CGI interface also allows applications to access the line 
drawing, polygon and text manipulation, and window-management microcode 
of the T4 directly from C-language subroutines. Occupies a single slot on the 
RT’s peripheral bus. Cost: $3200. Microfield Graphics, Inc., 8285 SW Nimbus 
Ave., Ste. 161, Beaverton, OR 97005; (503) 626-9393. 


83 


Intelligent Data Personal 

Systems, PC-88 computer 


This IBM PC-XT-compatible computer is equipped with a 16-bit Intel 8088-2 mi- 84 
croprocessor and an MS-DOS 2.11 operating system and has speeds of 4.77 or 8 
MHz and RAM from 256 to 640K bytes. Included is a dual 5.25-inch 360K-byte 
floppy disk, 8 full-length expansion slots, serial and parallel printer ports, game 
port, clock, and a 135-W power supply. Operates with all IBM software and other 
software written in GW Basic, Cobol, Pascal, and Fortran. Suggested retail 
price: $1275. Intelligent Data Systems, Inc., 14932 Gwenchris Ct., Paramount, 

CA 90723; (213) 633-5504. 


AST Research, 
Inc., 

TurboLaser 


Laser printer An eight-page-per-minute printer with a 300 dots-per-inch engine that runs on 85 
the IBM PC, XT, AT, and compatibles. With its 1.5M-byte memory capacity and 
the plug-in board controller, the printer supports word-processing, graphics, 

CAD, CAE, and desktop publishing applications. Cost: $4995. AST Research, 

Inc., 2121 Alton Ave., Irvine, CA 92714; (714) 863-1333. 


TeleVideo Personal 

Systems, Inc., computer 

TeleCAT-286 


An AT-compatible computer with a footprint of 16X 16.5 inches, 512K bytes of 86 
RAM, five expansion I/O slots, serial and parallel ports, a clock/calendar with 
battery backup, a high-resolution video monitor, and an MS-DOS operating sys¬ 
tem. Cost: with 20M-byte drive, $2995. Television Systems, Inc., 550 E. Brokaw 
Rd., PO Box 6602, San Jose, CA 95150-6602; (408) 745-7760. 


Office Automation Laser printer 
Systems, Inc., 

LaserPro 

EXPRESS 


Datapoint Corp., Desktop laser 

Starbeam printer 


An eight-page-per-minute laser printer with a Mita engine and 384K bytes of 87 

memory that outputs face-up and and face-down for consecutive paging. With 
10 bit-mapped fonts and facilities for bolding, italicizing, and condensing, it 
offers 72 font variations. Other features: 250-sheet paper cassette for 
8.5X 11-inch paper; 100-sheet capacity tray; and a user-changeable drum with an 
estimated life of 15,000 sheets. Compatible with several word-processing and 
spreadsheet programs. Available July 1986. Cost: $1895. OASYS, 8352 
Clairemont Mesa Blvd., San Diego, CA 92111; (619) 576-9500. 

Operable in an ARC LAN or stand-alone environment, this desktop laser printer 88 
features an eight-page-per-minute speed, a dry monocomponent electrographic 
printing method, a Courier 10 typeface (with 150 commercially available fonts), 

300 dots-per-inch resolution, and portrait and landscape print orientations. Price 
$2400. Datapoint Corp., 9725 Datapoint Dr., San Antonio, TX 78284; (512) 

699-7542. 
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MANUFACTURER 
AND MODEL 


FUNCTION 


COMMENTS 


R.S. 

NO. 


Cordata, 

LP-300X 


Sabtech 
Industries, PC- 
NTDS, AT-NTDS 


Canon USA, Inc., 
A-200II 


Pragmatic 
Computer, Inc., 
Industrial Buss PC 


Datapoint Corp., 
Starserver 


Datavue Technical 
Systems, 

8612 


Tektronix, Inc., 
SPD 


Datapoint Corp., 
Deskstar 


Desktop laser A desktop laser graphics printer able to produce a full page of high-resolution 

printer (330x 300 dots per inch), bit-mapped images in 18 seconds. With 1.25M bytes of 

memory and 38 diskette-based, downloaded fonts,the printer is also Epson MX- 
and RX-compatible. Cost: $3895. Cordata, 275 E. Hillcrest Dr., Thousand Oaks, 
CA 91360; (805) 495-5800. 


Interface Interfaces for the IBM PC, XT, AT, and compatibles provide full duplex 32-bit I/O 90 

adapter cards support for communications with Navy tactical computers AN/UYK-7, 

AN/UYK-20, AN/UYK-43, and AN/UYK-44. Features on-board RS-422 
communications port. PC/XT version conforms to MIL-STD-1397B with optional 
support for MIL-STD-1397A. AT version supports both fast and slow and 16-bit 
data path. Used to develop, test, and simulate Navy tactical software. Cost: PC- 
NTDS, $1600; AT-NTDS, $2850. Sabtech Industries, 4091 E. La Palma Ave., Unit 
“P,” Anaheim, CA 92807; (714) 630-9335. 


Personal An IBM PC-compatible PC utilizing the 8086 16-bit microprocessor with two 91 

computer clock speeds—4.77 and 7.16 MHz. Available in the floppy disk model, with two 

5.25-inch drives, each with 360K bytes; or in the hard disk one, with one floppy 
and a 20M-byte hard drive. Both with a choice of color/graphic or monochrome 
monitor and of a standard or a word-processing keyboard. Cost, with mono¬ 
chrome CRT, of the floppy model, $1995; of the hard disk model, $3595. Canon 
USA, Systems Division, One Canon Plaza, Lake Success, NY 11042. 


Industrial A rack-mount industrial computer configurable, through its 10-position card 92 

personal cage, with plug-in CPU cards compatible with the IBM PC/XT or/AT. With a built- 

computer in 9-inch color graphics monitor available in a 320- X 200-pixel or 

640-X 350-pixel display, a light pen, a 3.5-inch fixed disk drive, 360K-byte floppy 
disk drive, and a 250-W switching power supply with temperature-and fault¬ 
sensing circuitry. Pragmatic Computers, Inc., 1700-12 Wyatt Dr., Santa Clara, CA 
95054; (408) 986-9350. 


ARC file server An IBM PC/AT-compatible ARC file server for networks using the DOS operating 93 
system designed for small data entry and distributed data-processing networks. 
User-installable, it supports up to 16 on-line DOS volumes containing a 
maximum of 12.5M bytes disk storage each. Shipped with the MS-DOS 
operating system and file server software. Cost: $11,495. Datapoint Corp., 9725 
Datapoint Dr., San Antonio, TX 78284; (512) 699-7542. 


Personal A single-board PC with a full-sized PC expansion card and a NEC V-30 or INTEL 94 

computer 8086-1 microprocessor operating at 10 MHz. Through its ROM BIOS the PC is 

compatible with IBM PC software; and with its IBM 62 pin card edge 
connectable to a female edge connector, it can support the IBM PC bus. Cost, 
at the 50 quantity level: $626. Datavue Technical Systems, 4355 International 
Blvd., PO Box 2687, Norcross, GA 30093; (404) 564-5780. 


Signal¬ 
processing and 
display 
programs 


A waveform processing, display, and data structure manipulation software pack- 95 
age for the IBM PC/XT or AT offering more than 190 processing functions for 
users at every programming level. Written in C language, featuring a menu- 
driven mode, and offering a Basic interface, the program requires an IBM PC 
with a minimum of 256K bytes of memory, a hard disk, and a color graphics 
display monitor. For Basic users, compatible with the IBM Basic version 1.0 
compiler; for C users, Lattice C, version 2.15. Tektronix, Inc., PO Box 500, 

Beaverton, OR 97077; (503) 644-0161. 


Applications A single-user workstation for data-processing and office automation in an RMS 96 
processor ARC local area network and incorporating the Intel 80286 microprocessor. 

Features a 14-X 13-inch base, tilt/rotate 14-inch monitor, amber-on-gray display, 
adjustable brightness and contrast levels, and extended function keyboard. 

Cost: $3995. Datapoint Corp., 9725 Datapoint Dr., San Antonio, TX 78284; (512) 

699-7542. 
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Recent 1C Announcements 


For more information, circle the appropriate RS No. on the Reader Service Card at the back of the magazine. 


MANUFACTURER R.S. 

AND MODEL FUNCTION COMMENTS NO. 


InTech, Inc., 

RGB DAC 4C 

Digital-to- 

analog 

converter 

A hybrid CMOS triple 4-bit color-mapped video digital-to-analog converter with 
three channels of video output for RGB-type video displays with pixel rates to 

40 MHz. Contains three video D/A converters and three 16X4 RAM arrays. 
Hermetically sealed in a 24-pin side brazed ceramic package, it is also TTL- 
compatible and operates from a single + 5-V power supply and has a 
temperature range of 0—1- 70° C. Cost $70 (1000’s). Intech, Inc., 2270 Martin 

Ave., Santa Clara, CA 95050-2781; (408) 988-4930. 

Harris Microwave 

Semiconductor, 

HMD-11113-2 

OR logic gate 

An ECL-compatible GaAs dual 2-input OR gate with a 2.5 GHz data input rate 
and a propagation delay of 650 ps operational at - 5-+ 85° C, it also features a 
50-0 line driving capability and output fanout of three into a 50-0 terminated 
transmission line. Typical dissipation is 1.5 W. Cost: $224 (100’s). Harris Micro- 
wave Semiconductor, 1530 McCarthy Blvd., Milpitas, CA 95035; (408) 262-2222. 

Silicon Systems, 
SSI 6220 

Digital-to- 

analog 

converter 

Based on an R-2R ladder of diffused resistors with precision bipolar voltage 
switches, this monolithic converter has a circuit with an on-chip precision 
bandgap reference requiring only one external resistor and a capacitor. With a 
settling time of 1 ^s, TTL and CMOS compatible, and operating off a single 
+ 5-V power supply, the 1C is available in military and commercial temperature 
ranges. Cost of moulded DIPs is $4 (1000’s). Silicon Systems, 14351 Myford Rd., 
Tustin, CA 92680; (714) 731-7110. 

LMS Electronics, 
GR281 and GR881 

Nonvolatile 

RAMs 

These RAMs with low-power CMOS design and power-down circuitry have a 
built-in lithium battery with a life of 10 years. Performance specifications 
include 1 200-ns read/write time and a 25- and 5-mA current. An internal power- 
up delay enables voltage stabilization before read/write occurs. Cost for GR281 
(2KX 8) is $16.80 (1000’s); for GR881 (8KX 8), $28.80 in like quantities. LMS 
Electronics, 3401 Monroe Rd„ Charlotte, NC 28205; (704) 376-7805. 

S-MOS Systems, 
Inc., 

SRM 20256 

Static RAM 

A 256K-bit static RAM with a maximum access time of either 100 or 120 ns, this 
32K-bit X 8-bit asynchronous device has an operating and standby current of 

37 mA and 5 jiA, respectively. Inputs and outputs are TTL-compatible. Comes in 
28-pin dual-in-line and SOP plastic packages. Cost (100-piece quantities) for the 
120-ns version is $40.50; for the 100-ns version, $45. S-MOS Systems, Inc., 50 W. 
Brokaw Rd., Bldg. 7, San Jose, CA 95110; (408) 993-1212. 

Silicon Systems, 
SSI 521 

Read/write 1C 

A 6-channel read/write device for thin-film recording heads for use in 3.5- and 
5.25-inch Winchester disk drive systems and compatible with non-center-thin 
film heads. Features a low-noise path of 0.9 nV/Hz, uses + 5- and + 12-V power 
sources, available as a 28-pin PDIP, flatpack, and PLCC. Cost of PLCCs is $15 in 
OEM quantities. Silicon Systems, 14351 Myford Rd., Tustin, CA 92680; (714) 
731-7110. 

Fairchild 
Semiconductor, 
UA6685, UA685 

Comparators 

These latched comparators with complementary ECL outputs are pin- 
compatible with Analog Devices AD9684 and Plessey SP9680 and can be 
specified to industrial (-30 -85° C)or extended (-55-125° C) temperature 
ranges. Available in 14-pin molded surface mount packages, 10-pin metal cans, 
and 14-pin ceramic DIPs. The UA6685 has propagation delays of 2.7 ns; the 
UA685, 6 ns. Price range for all versions of the UA6685 is $14-$21 (100’s); for all 
versions of the UA685, $9.50-$22 (100’s). Fairchild Semiconductor Corp., 10400 
Ridgeview Ct., PO Box 1500, Cupertino, CA 95014; (408) 864-6250. 


Toshiba America, Dynamic RAMs Built with n-channel, silicon gate process technology, these DRAMs operate 77 

Inc., from single 5-V power supplies, are interface-compatible with high-performance 

TMM41256T and logic familes such as Schottky TTL, and are organized as 262,144-bit words. The 

TMM41257T 41256 offers page mode capability; the 41257, nibble mode capability and CAS- 

before-RAS refresh mode. Both devices offer read-modify-write, RAS only 
refresh and hidden refresh modes, are available with acces times of 120 or 150 
ns, and have a maximum operating power of 385 mW or less (depending on the 
version). Available in PLCC package and offering J-lead construction. Cost for 
the 41256 is $3.25 (10,000’s); for the 41257, $3.50 (10,000’s). Toshiba America, 

2692 Dow Ave., Tustin, CA 92680; (714) 832-6300. 
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IEEE COMPUTER SOCIETY’S WORKSHOP ON 
DESIGN PRINCIPLES FOR EXPERIMENTAL DISTRIBUTED SYSTEMS 
October 16 - 17,1986 
Purdue University Sponsored by IEEE Computer 

West Lafayette, Indiana 47907 Society in cooperation with 

Purdue University 



The purpose of this limited attendance workshop is to bring together researchers, designers, and 
implementers of experimental distributed systems to share experiences. The following topics are of special 
interest: 

• Fault-tolerance, availability, performance 

• Replicated objects (data) and consistency 

• Real-time operating systems 

• System level support for transaction based database systems 

• Nested transactions/atomic actions 

• Inter-process communication/RPC 

• Atomic broadcasts/quorum mechanisms 

• Distributed name management 

• Process groups 

With the advice of the program committee, approximately fifty participants will be invited. 


PROGRAM COMMITTEE: 

Rakesh Agarwal, AT&T; Bharat Bhargava, Purdue; Ken Birman, Cornell; Luis Cabrera, IBM; Doug¬ 
las Comer, Purdue; Ed Foudriat, NASA; Douglas Jensen, CMU; Walter Kohler, U of Mass; Mike Liu, 
OSU; Bob Lyon, SUN; William McDonald, SDC; Howard Sturgis, Xerox; Anand Tripathi, U of Minn. 


PUBLICATIONS: 

A summary of the workshop including the selected extended abstracts will appear in the IEEE TC- 
DP newsletter. A special issue of IEEE Transactions on Software Engineering has been approved to cover 
the research focus of this workshop. 

Please send thirteen copies of up to two pages extended abstract containing the focus of your 
research/experimental efforts to 

Professor Bharat Bhargava 
Department of Computer Science 
Computer Science Building 
Purdue University 
West Lafayette, Indiana 47907 
bhargava@purdue.arpa 

IMPORTANT DATES: 

Submission deadline: July 15, 1986 
Final Program: September 15, 1986 

Workshop: October 16-17,1986 


LOCATION/ACCOMMODATIONS/COSTS: 

The workshop will be held on the campus of Purdue University. Convenient housing has been 
arranged in the Purdue Memorial Union. Brett Air connections to/from Chicago O’Hara and limosine ser¬ 
vice to/from Indianapolis International are available. The cost is approximately $125.00 including break¬ 
fasts, luncheons, dinners and reception. 








NEW LITERATURE 


Expert systems for PCs. A general guide 
to implementing AI applications on PC, 
this book also presents techniques that 
can be used to develop individualized, 
PC-based expert or knowledge systems 
in the Forth language. Designing and 
Programming Personal Expert Systems, 
Tab Books, Inc., Blue Ridge Summit, 

PA 17214; (717) 794-2191; $18.45 in 
paperback and $27.95 in hardcover. 

Directory of AI firms. Lists more than 
300 companies actively involved in the 
business of artificial intelligence, expert 
systems, voice recognition systems, ar¬ 
tificial vision, natural language, symbolic 
computing, and AI programming lan¬ 
guages. The Artificial Intelligence Direc¬ 
tory, 1986 edition, DM Data, Inc., 6900 
E. Camelback Rd., Suite 1000, Scotts¬ 
dale, AZ 85251; (602) 945-9620; $49.95. 

AI directory. Includes the names and 
addresses of 200 AI companies, informa¬ 
tion on their activities, descriptions of 
their software and hardware products, 
their consultancy services, and their 
training opportunities. Also gives infor¬ 
mation on universities and research 
centers involved in AI, AI publications 
and publishers, AI associations, con¬ 
ferences and congresses, and includes a 
glossary of AI terms. The International 
Directory of Artificial Intelligence Com¬ 
panies, second edition, Artificial In¬ 
telligence Software S.r.l., Via A. Mario 
12/A, 45100 ROVIGO, Italy; $50. 

CAD/CAE marketplace. This report 
predicts that the PC CAD/CAE market 
will be dominated by third-party 
distribution in the future, and that 
CAD/CAE outlets will double to 4000 
by 1990. It also provides guidelines for 
developing and managing a third-party 
distribution network. The Profitable 
Distribution of Low-Cost CAD/CAE 
Hardware, Software, and Systems: Ven¬ 
dor Strategies, Third-Party Channels, 
Retail Outlets, Technology and Business 
Communications, Inc., 730 Boston Post 
Rd., PO Box 915, Sudbury, MA 01776; 
(617)443-4671. 

CAD for VLSI. Representing the com¬ 
bined efforts of 68 specialists from 
around the world, Advances in CAD for 
VLSI is a handbook series that contains 
seven titles: Process and Device Model¬ 
ing; Logic Design and Simulation; Cir¬ 


cuit Analysis, Simulation, and Design; 
Layout Design and Verification; VLSI 
Testing; Design Methodologies; and 
Hardware Description Languages. Each 
volume can be read independently. 
North-Holland, PO Box 1991, 1000 BZ 
Amsterdam, The Netherlands; phone 
(020) 5862 467 or Elsevier Science 
Publishing Co., Inc., PO Box 1663, 
Grand Central Station, New York, NY 
10163; (212) 916-1009. 

IWS in the workplace. Aimed at infor¬ 
mation systems managers, this study 
finds that intelligent workstations (IWS) 
offer communications capabilities that 
are unavailable in microcomputers, as 
well as local processing advantages that 
terminals cannot provide. It gives advice 
on deciding whether the use of IWS will 
benefit a company and, if the answer is 
affirmative, how to integrate such work¬ 
stations into the firm. Intelligent Work¬ 
stations: Connecting the End User, In¬ 
put, 1943 Landings Dr., Mountain View, 
CA 94043; (415) 960-3990. 

Logic programming. A textbook/tutorial 
software combination, based on Prolog, 
that is designed to explain the concepts 
of logic programming. The MProlog 
Primer, Logicware, 1000 Finch Ave. 

West, Toronto, Ontario M3J 2V5, 
Canada; $49.95 for book and software. 

Object-oriented programming. This 
book covers the topics of objects, 
classes, instances, message passing, 
method cells, meta-classes, and multiple 
inheritance, as well as MacApp, the Ex¬ 
pandable Macintosh Application. 
Object-Oriented Programming for the 
Macintosh, Hayden Book Co., Box PPI, 
10 Mulholland Dr., Hasbrouck Heights, 
NJ 07604; $34.95. 

Monographs for application engineers. 

NES Notes is an educational series on 
technical/application topics that is 
designed to aid the application or in¬ 
strumentation engineer. The topic of the 
first Note, which is entitled “Open Col¬ 
lector Outputs,” was determined by a 
survey of over 10,000 of NES’s cus¬ 
tomers. Planned future topics include 
temperature measurement techniques, 
RS-232, programmable controller inter¬ 
facing, AC measurement theory, and 
proper wiring practices. NES Notes, Na¬ 
tionwide Electronic Systems, Inc., 3003 
Wakefield Dr., Carpentersville, IL 60110; 
(312) 426-5900. 


Liaison service. Success Sensor is a 
monthly magazine founded to match 
North American businesses with 
Japanese partners who will help the 
businesses market their goods in Japan. 
Representatives from Trans Pacific Con¬ 
nection, a New York division of the 
publishing company, Shin-Nihon Kohan 
Co., Ltd. of Tokyo, take telephone calls 
from North Americans with business 
proposals and meet with the persons 
whose ideas are considered promising. 
Selected ideas are then forwarded to the 
parent company to consider for publica¬ 
tion. The magazine is distributed to 
Japanese firms at no cost to the Amer¬ 
ican suppliers of information. Other 
liaison services available. Trans Pacific 
Connection, (800) 872-6772. 

Forth application programs. This three- 
volume, on-disk library offers applica¬ 
tion programs compatible with Forth-83 
systems. Titles: A Forth List Handler, 
which extends Forth with list primitives 
to provide an environment for artificial 
intelligence; A Forth Spreadsheet-, and 
Automatic Structure Charts, which pro¬ 
vides tools for the analysis of large Forth 
programs. Forth Model Library, Vols. 
1-3, Forth Interest Group, PO Box 8231, 
San Jose, CA 95155; (408) 277-0668. 


Ring-based LANs. Discusses the poten¬ 
tial for IBM to shape the future of the 
LAN industry with its Token-Ring Net¬ 
work and compares the three basic ring- 
based LANs: slotted ring, token-passing, 
and the register-insertion ring. The Ring- 
Based Local Networks Report, Architec¬ 
ture Technology Corp., PO Box 24344, 
Minneapolis, MN 55424; (612) 935-2035; 
$245 in US and $295 outside US. 

Guide to engineering software. The 

eighth edition of a publication formerly 
titled Microprocessor Technical Soft¬ 
ware, this book contains information on 
more than 3400 application packages 
designed for engineers. The book is 
cross-referenced by application/func- 
tion, processor, package name, operating 
system, and vendor; more than 200 ven¬ 
dors are represented. Engineering Ap¬ 
plication Software, D.A.T.A., Inc., 9889 
Willow Creek Rd., PO Box 26875, San 
Diego, CA 92126-0875; (800) 854-7030 in 
US, (416) 238-0366 in Canada, and 
(0) 732-866013 in Europe. 
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8th SYMPOSIUM on 

COMPUTER ARITHMETIC 


ARITH 8 


=30 


MAY 18-21, 1987 
COMO, ITALY 


Sponsored by the Technical Committee on Computer Architecture (TCCA) 
IEEE Computer Society 
and 

Politecnico di Milano 

CALL FOR PAPERS 


Authors are invited to submit papers describing new applied and theoretical developments in 
computer arithmetic, including but not restricted to the following topics: 

• Mathematical Foundations of Computer Arithmetic 

• Arithmetic Algorithms and their Analysis 

• Arithmetic Algorithms and their Implementation in VLSI 

• Arithmetic Issues in Signal and Image Processing 

• Arithmetic and Logic Issues in Fifth Generation Computing 

• Arithmetic Processors for Large Scale Scientific Computations 

• Numerical Error Control and Error Analysis 

• High Level Language Support for Numerical Computations 


Four (4) copies of the complete paper (in English, not exceeding 20 double-spaced typed pages) 
should be submitted to the appropriate Program Chairman no later than October 1, 1986. Au¬ 
thor identification should only appear on a separate sheet. Authors will be notified of accep¬ 
tance by January 1, 1987 and final camera ready papers will be due by February 1, 1987. 
Proceedings will be available at the symposium. 


General Chairman 

Luigi Dadda 

Department of Electronics 
Piazza Leonardo da Vinci, 32 
Politecnico di Milano 
1-20133 Milano, ITALY 
Phone: (02) 2 367 241 


Program Co-Chairman 

Mary Jane Irwin 
Dept, of Computer Science 
333 Whitmore Laboratory 
Pennsylvania State University 
Univ. Park, PA 16802 USA 
Phone: (814) 865-1802 


Program Co-Chairman 

Renato Stefanelli 
Department of Electronics 
Piazza Leonardo da Vinci, 32 
Politecnico di Milano 
1-20133 Milano, ITALY 
Phone: (02) 3 993 513 
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CALENDAR 


July 1986 


Workshop on Software Testing (ACM), 
July 15-17, Banff, Alberta, Canada. 
Contact Lori Clark, University of Massachu¬ 
setts, Amherst, MA 01003; (413) 545-1328. 

ICALP-86, 13th Annual Colloquium on 
Automata, Languages, and Programming of 
the European Association for Theoretical 
Computer Science (INRIA), July 15-19, 

Rennes, France. Contact Elisabeth Lebret, 
IRISA-INRIA, Campus de Beaulieu, 

F-35042 Rennes Cedex, France; phone 
99-36-20-00 or Sylviane Gosset, INRIA- 
Bureau des Colloques, BP 105, F-78153 Le 
Chesnay Cedex, France; phone 3-954-90-20. 

International Computers in Engineering Con¬ 
ference and Exhibition (ASME), July 20-24, 

Chicago, Illinois. Contact ASME Meetings 
Dept., 345 E. 47th St., New York, NY 10017; 
(212) 705-7788. 

Montreal Symposium on Speech Recognition, 
July 21-22, Montreal, Canada. Contact 
Secretariat, Montreal Symposium on Speech 
Recognition, c/o Bell-Northern Research, 3 
Place du Commerce, Nuns’ Island, Verdun, 
PQ H3E 1H6, Canada. 

Symsac 86, 1986 ACM Sigsam Symposium on 
Symbolic and Algebraic Computation, July 
21-23, Waterloo, Ontario, Canada. Contact 
Richard Fateman, University of California, 
Dept, of Electrical Engineering and Computer 
Science, Berkeley, CA 94720; (415) 642-1879. 

ECAI-86, European Conference on Artificial 
Intelligence, July 21-25, Brighton, England. 
Contact Benedict du Boulay, The University 
of Sussex, Cognitive Studies Programme, 
Brighton BN1 9QN, UK; phone (44) (0) 
273-683 500. 

SIAM 1986 National Meeting, July 21-25, 

Boston, Massachusetts. Contact SIAM Con¬ 
ference Coordinator, 117 S. 17th St., 14th 
floor, Philadelphia, PA 19103-5052; (215) 
564-2929. 

International Congress on Computational and 
Applied Mathematics, July 21-26, Leuven, 
Belgium. Contact Luc Wuytack, Dept, of 
Mathematics and Computer Science, Univer¬ 


sity of Antwerp—UIA, Universiteitsplein 1, 
B-2610 Antwerp/Wilrijk, Belgium. 

Third International Workshop on 
Statistical Scientific Database Manage¬ 
ment, July 22-24, Luxembourg Study Center, 
Luxembourg. Contact Roger Cubitt, Unit for 
Data Processing Management, Eurostat, BP 
1907, L-1019 Luxembourg. 

Sixth International Conference in Computer 
Science (IEEE), July 28-30, Santiago, Chile. 
Contact Gaston H. Gonnet, Dept, of Com¬ 
puter Science, University of Waterloo, 
Waterloo, Ontario N2L 3G1 , Canada. 

1986 Summer Computer Simulation Con¬ 
ference (AIAA, AIChE, BES, IEEE, IMACS, 
ISA), July 28-30, Reno, Nevada. Contact 
Society for Computer Simulation, PO Box 
17900, San Diego, CA 92117; (619) 277-3888. 

Workshop on Teaching Computers and the 
Humanities Courses, July 31-August 2, 

Poughkeepsie, New York. Contact Elle Gohl, 
Dept, of Computer Science, Box 252, Vassar 
College, Poughkeepsie, NY 12601; (914) 
452-7000. 


August 1986 

ACM Conference on LISP and Functional 
Programming, August 4-6, Cambridge, 
Massachusetts. Contact Richard P. Gabriel, 
Lucid, Inc., 707 Laurel St., Menlo Park, CA 
94025; (415) 329-8400. 

ACM Sigcomm 86, Symposium on Commu¬ 
nications Architectures and Protocols, Augusi 
5-7, Stowe, Vermont. Contact Walter Kosin- 
sky, Post Road Iron Works, PO Box 4328, 

345 W. Putnam Ave., Greenwich, CT 06830; 
(203) 869-6322. 

Fifth ACM Sigact-Sigops Symposium on 
Principles of Distributed Computing, August 
11-13, Calgary, Alberta, Canada. Contact J. 
Halpern, Dept. K53/801, IBM Almaden Re¬ 
search Center, 650 Harry Rd., San Jose, CA 
95120-6099. 

AM/FM Conference IX: Integrating 
Automated Mapping/Facilities Management 


(AM/FM) Technology: The Corporate 
Resource, August 11-14, Snowmass, Col¬ 
orado. Contact Barbara Emery, AM/FM In¬ 
ternational, 8775 E. Orchard Rd., Suite 820, 
Englewood, Colorado 80111; (303) 779-8320. 

AAAI-86, National Conference on Artificial 
Intelligence (AAAI), August 11-15, Phila¬ 
delphia, Pennsylvania. Contact AAAI-86, 
AAAI, 445 Burgess Dr., Menlo Park, CA 
94025-3496. 

SIAM Conference on Linear Algebra in 
Signals, Systems, and Control, August 12-14, 

Boston, Massachusetts. Contact SIAM Con¬ 
ference Coordinator, Suite 1400, 117 S. 17th 
St., Philadelphia, PA 19103-5052. 

30th Annual International Technical Sym¬ 
posium on Optical and Optoelectronic Engi¬ 
neering, August 17-22, San Diego, California. 
Contact SPIE, PO Box 10, Bellingham, WA 
98227-0010; (206) 676-3290 or SPIE, Ave. de 
la Tanche 2, B-l 160 Brussels, Belgium; phone 
2/660-45-11. 

Eighth Non-Volatile Semiconductor Memory 
Workshop (IEEE), August 18-20, Vail, Col¬ 
orado. Contact Michael Knoll, Division 2115, 
Sandia National Labs, Albuquerque, NM 
87185; (505) 844-0568. 

ACM Siggraph 86, 13th Annual Conference 
on Computer Graphics and Interactive 
Techniques, August 18-22, Dallas, Texas. 
Contact Siggraph 86 Conference Manage¬ 
ment, 111 E. Wacker Dr., Suite 600, Chicago, 
IL 60601; (312)644-6610. 

Tutorial Week Los Angeles 86, August 
18-22, Marina del Rey, California. Con¬ 
tact Tutorial Week Los Angeles 86, IEEE 
Computer Society, 1730 Massachusetts Ave., 
NW, Washington DC 20036-1903; (202) 
371-0101; TWX 7108250437 IEEECOMPSO. 

15th Annual International Conference 
on Parallel Processing (ACM), August 
19-22, St. Charles, Illinois. Contact Tse-Yun 
Feng, Dept, of Electrical Engineering, EE 
East Bldg., Pennsylvania State University, 
University Park, PA 16802; (814) 863-1469. 

International Conference on Systems, 
Research, Informatics, and Cybernetics, 
August 19-24, Baden-Baden, West Germany. 
Contact George E. Lasker, School of Com¬ 
puter Science, University of Windsor, Wind¬ 
sor, Ontario N9B 3P4, Canada. 

Applying Machine Vision to Your Manufac¬ 
turing Process: A Hands-On Workshop 
(SME), August 20-22, Cambridge, Massachu¬ 
setts. Contact Joanne Rogers, Society of 
Manufacturing Engineers, One SME Dr., PO 
Box 930, Dearborn, MI 48121; (313) 
271-0039. 


Conferences that the Computer Society participates in or sponsors are indicated by the 
IEEE Computer Society logo; other conferences of interest to our readers are also includ¬ 
ed. For inclusion in Calendar, submit information six weeks before the month of publica¬ 
tion (e.g., for the October 1986 issue, send information for receipt by August 15,1986) to 
COMPUTER, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720. 
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CALL FOR PAPERS 


Call for papers for Computer 


Computer magazine seeks articles that 
cover the state of the art and important 
new developments in computer science, 
technology, and applications. Aimed at a 
broad audience with diverse interests and 
experience, Computer usually publishes 
surveys or tutorials that facilitate the 
transfer of technology from university to 
industry, from research to applications, 
and across specialized fields. Submit six 
copies of the manuscript, including illus¬ 
trations, references, and authors’ biogra¬ 
phies, to the editor-in-chief: 

• Michael C. Mulder 
Applied Research 
University of Portland 
Portland, OR 97203 
Phone (503) 283-7433 


Computer also seeks articles on topics 
relevant to upcoming special issues. Sub¬ 
mit six copies of the manuscript directly 
to the guest editor: 


• FAA’s Advanced Automation Pro¬ 
gram: Submit by July 15, 1986, to 
G. V. Kloster, 301 Dexter, Denver, 
CO 80220. 

Lastly, Computer seeks special issue pro¬ 
posals and articles in the following topic 

• microprocessor architectures 

• networking and distributed 
computing 

• computer-integrated manufacturing 

• software quality assurance 

• programming environments 

Prospective guest editors and authors 
should submit proposals and articles 
directly to Michael Mulder. 

An authors’ information sheet can be ob¬ 
tained from Michael Mulder at the above 
address or from the IEEE Computer So¬ 
ciety West Coast Office, 10662 Los Va- 
queros Circle, Los Alamitos, CA 90720; 
(714) 821-8380. 


International Journal for Artificial In¬ 
telligence in Engineering: This journal em¬ 
phasizes research and development leading to 
problem solving. Write for submission re¬ 
quirements to D. Sriram, Dept, of Civil Engi¬ 
neering, Carnegie-Mellon University, Pitts¬ 
burgh, PA 15213 or K. J. MacCal'lum, Dept, 
of Ship and Marine Technology, Marine Tech¬ 
nology Centre, 100 Montrose St., Glasgow, 
UK. 

Robots ll/17th International Symposium on 
Industrial Robots (SME): April 26-30, 1987, 
Chicago, Illinois. Send abstract (approximate¬ 
ly 100 words) and abstract submission form 
(available from Mike Tew at RI/SME) by 
July 15,1986, to RI/SME, One SME Dr., PO 
Box 930, Dearborn, MI 48121; (313) 271-1500, 
ext. 359, telex 297742 SME UR (via RCA). 

24th Annual Allerton Conference on Com¬ 
munication, Control, and Computing: Octo¬ 
ber 1-3, 1986, Monticello, Illinois. Papers 


suitable for 20-minute and 10-minute presen¬ 
tations are sought. Papers in the first category 
will be judged on the basis of a 1000-word 
summary, and papers in the second will be 
judged on the basis of a 500-word summary. 
Submit all materials by July 28,1986, to 
Michael C. Loui, Coordinated Science Labo¬ 
ratory, University of Illinois at Urbana-Cham- 
paign, 1101 W. Springfield Ave., Urbana, IL 
61801. 

Second International Conference on Robotics 
and Factories of the Future: March 24-27, 
1987, Salt Lake City, Utah. Submit two 
copies of abstract (maximum 500 words/one 
single-spaced typewritten page) by July 31, 
1986, to R. Radharamanan, Dept, of Me¬ 
chanical and Industrial Engineering, College 
of Engineering, University of Utah, Salt Lake 
City, UT 84112. 

ICS-86, International Computer Symposium: 

December 15-19, 1986, Tainan, Taiwan, 


Calls are listed according to submittal deadlines. Conferences that the Computer Socie¬ 
ty participates in or sponsors are indicated by the IEEE Computer Society logo; others 
of interest to our readers are also included. For inclusion in “Call for Papers,” submit 
information six weeks before the month of publication (e.g., for the October 1986 issue, 
send information for receipt by August 15,1986) to COMPUTER, 10662 Los Vaqueros 
Circle, Los Alamitos, CA 90720. 


Republic of China. Tutorials and papers on 
all aspects of computer science, computer en¬ 
gineering, and information-processing 
technology are solicited. Send a 200-word 
abstract and the manuscript (20 pages max¬ 
imum) by August 1, 1986, to Ming T. Liu, 
Dept, of Computer and Information Science, 
Ohio State University, 2036 Neil Ave., 
Columbus, OH 43210-1277; (614) 422-1837. 


IEEE Infocom 87: Global Networks — 
Concept to Realization: March 30- 
April 2, 1987, San Francisco, California. Sub¬ 
mit four copies of the complete paper by 
August 1, 1986, to Izhak Rubin, 6731 Boelter 
Hall, Electrical Engineering Dept., The 
University of California at Los Angeles, Los 
Angeles, CA 90024; (213) 825-2327. 


Second Kansas Conference: Knowledge-Based 
Software Development: October 13-14, 1986, 
Manhattan, Kansas. Papers and proposals for 
panel discussions are sought. Submit five 
copies of complete paper and of proposals by 
August 1,1986, to David A. Gustafson, 
Computer Science Dept., Nichols Hall, 

Kansas State University, Manhattan, KS 
66506; (913) 532-6350. 


Fourth Symposium on Theoretical Aspects of 
Computer Science (AFCET, Gesellschaft fur 
Informatik): February 19-21, 1987, Passau, 
West Germany. Submit seven copies of a draft 
paper (five to 12 pages) by August 15,1986, 
to Martin Wirsing, Fakultat fur Mathematik 
und Informatik, Universitat Passau, Inn- 
straBe 27, D-8390 Passau, West Germany. 


Sixth Annual Research Conference of the Of¬ 
fice Systems Research Association: March 
21-22, 1987, New York, New York. Submit a 
full-length paper (suitable for a 20-to-30- 
minute presentation) or a 500-word synopsis 
with a detailed outline of the proposed pre¬ 
sentation by August 15, 1986, to Elizabeth A. 
Regan, Massachusetts Mutual Life Insurance 
Co., Room B 303, 1295 State St., Springfield, 
MA 01111; (413) 788-8411, ext. 5184. 


ECS-87, 1987 Eastern Simulation Conference 
(SCS): April 6-9, 1987, Orlando, Florida. 
Abstracts for papers on the following topic 
areas are solicited: simulators, the simulation 
profession, tools for the simulationist, 
methodology and validation, and simulating 
the environment. Submit abstracts by August 
31,1986, to Denis LeClair, SCS, PO Box 
17900, San Diego, CA 92117; (619) 277-3888. 


Operations Research: Articles are solicited for 
a special issue on operations research in 
manufacturing. Submit papers by August 31, 
1986, to Gabriel R. Bitran, Sloan School of 
Management, Room E53-390, MIT, Cam¬ 
bridge, MA 02139; (617) 253-2652. 
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CAREER OPPORTUNITIES 


LAWRENCE 

BERKELEY 

LABORATORY 

COMPUTER SCIENTIST 


A Computer Scientist with strong research and 
leadership skills is being sought for a principal 
Investigator level postition in distributed com¬ 
puting systems research. Responsibilities will 
include leading the research and development 
activities of a small distributed computing group 
in the Computer Science Research Department. 
Preferably, the candidate will have a Ph.D. or 
equivalent and will have a strong background 
and publication record in network behavior, mod¬ 
eling, and measurement. However, the individual 
will be responsible for establishing thedirection 
of the group Into other aspects of distributed 
systems research and development. 

Present activities of the group are primarily con¬ 
cerned with local area network performance and 
analysis, protocol design, network modeling, 
and integration of supercomputers with the 
ARPA Internetwork. Distributed graphics, file¬ 
system, and databases also are of interest to the 
Laboratory. 

Other work in the department includes database 
management research, statistical analysis of 
ecologic summary data directed at epidemiolog¬ 
ical applications, and information systems 
development. Currently, members of the depart¬ 
ment interested in teaching hold joint appoint¬ 
ments with the Computer Science Deparment at 
UCB and SF State University. In addition, the par¬ 
ticipation of undergraduate and graduate stu¬ 
dents from both institutions in the department's 
research activities are common. 

A sophisticated hardware base, including token 
ring (10Mbit and 80Mbit) and CSMA/CD (10Mbit) 
local-area networks, local-area network moni¬ 
tors, and workstation computers, support the ac¬ 
tivities of the group. Generally available facilites 
include three VAX-11/780 timesharing hosts be¬ 
longing to the department, connections to 
MILNET, BITNET AND HEPNET, access to a lab¬ 
wide Ethernet (less than 150 hosts), and access 
to Cray X-MP and Cray-2 computation facilities 
provided by the Energy Research Computing 
Center. 

Lawrence Berkeley Laboratory, which is adja¬ 
cent to the Berkeley Campus of the University of 
California, is a multi-purpose reasearch laborato¬ 
ry funded by the U.S. Department of Energy. Ma¬ 
jor laboratory research programs include high 
energy physics, low energy nuclear physics, ma¬ 
terials science, biochemistry research medicine, 
and earth sciences. 

All candidates should write to the address below 
describing their professional interests and 
goals. SPECIFY JOB #C/3742. Applications 
should include a curriculum vitae and the names 
and addresses of three or more references. Addi¬ 
tional material describing the applicant's work, 
such as papers or technical reports would also 
be helpful. Send all applications to: Marina Gon¬ 
zalez #C/3742, Lawrence Berkeley Laboratory, #1 
Cyclotron Road, Bldg. 90-1012, Berkeley, CA 
94720. Lawrence Berkeley is an Equal Oppor¬ 
tunity/Affirmative Action Employer. U.S. citizen¬ 
ship is not required. 


ROCHESTER INSTITUTE OF TECHNOLOGY 
Faculty Position in Computer Engineering 

The Department of Computer Engineering an¬ 
ticipates having an excellent tenure-track faculty 
position available at the assistant/associate pro¬ 
fessor level beginning in December, 1986. Ap¬ 
plicants will be expected to have a strong in¬ 
terest and demonstrated ability to teach VLSI 
design and the ability to contribute to curricular 
evolution. Research in the areas of VLSI design, 
design automation, computer architecture, 
operating systems, and computer communica¬ 
tions will be encouraged. Computer Engineering 
faculty and students have regular use of at least 
9 large VAX systems, a CALMA VLSI design 
system and numerous workstations. The Depart¬ 
ment of Computer Engineering has recently 
completed a move to brand new facilities. This 
position affords unique opportunities to work in 
the hardware/software interface and to exercise 
significant influence on research, laboratories, 
and curricula. Applicants should have com¬ 
pleted a Ph.D. degree in computer engineering or 
a related area by the time of appointment. Ap¬ 
plicants should submit a resume and arrange for 
three letters of recommendation to be sent to Dr. 
Roy S. Czernlkowski, Department of Computer 
Engineering, Rochester Institute of Technology, 
Rochester, NY 14623. RIT is an equal opportunity 
affirmative action employer. 


MARKETING/TECHNICAL DIRECTOR 

Responsible for technical development and 
marketing of custom computer software. Devel¬ 
op specifications for programs, systems analy¬ 
sis for compatibility w/clients needs, systems 
design, product testing. Arrange contracts, ex¬ 
pand conduits of business, responsibility for 
advertising, supervise post-sale support. 
Requires 3-4 years bachelors degree, minimum 4 
years experience, familiarity with updated 
developments in systems and software, com¬ 
puter marketing experience. Salary 40K. Job site 
and interview in Los Angeles. Send this ad and 
your resume to Job #AT2238, P.O. Box 9560, 
Sacramento, CA 95823-0560 not later than 8/1/86. 


THE UNIVERSITY OF ALBERTA 
DEPARTMENT OF COMPUTING SCIENCE 

The Department of Computing Science is 
undergoing an extensive expansion in research 
initiatives. Applications are invited for three 
tenure-track positions at the Assistant/Associ¬ 
ate Professor level. Responsibilities include 
research as well as teaching at the graduate and 
undergraduate levels. Candidates from all areas 
will be considered. Current hardware support in¬ 
cludes an Amdahl 5870, a network of VAX 
11/780’s, and well equipped mini and micro com¬ 
puter laboratories for graphics, VLSI, and Al 
research. Access to a Cyber 205 is available. 
Salary range is $30,316 to $48,970 and is com¬ 
mensurate with qualifications and experience. 
Send curriculum vitae, names of three refer¬ 
ences, and up to three reprints or papers. New 
Ph.D.'s should also include a copy of their tran¬ 
script. Apply to: Dr. Lee White, Chairman, De¬ 
partment of Computing Science, University of 
Alberta, Edmonton, Alberta, T6G 2H1. Applica¬ 
tions will be accepted until August 31,1986. The 
University of Alberta is an equal opportunity 
employer. 


PORTLAND STATE UNIVERSITY 
POSITION ANNOUNCEMENT 

Electrical Engineering 

The Department of Electrical Engineering has 
tenure-track faculty positions at the Assistant, 
Associate or Full Professor level available im¬ 
mediately. Applicants must have an earned doc¬ 
torate. Areas of particular interest are VLSI 
Design, Interactive Computer Graphics, Com¬ 
puter Architecture, and Operating Systems. A 
VLSI design center, computer vision laboratory, 
and optical communications laboratory have re¬ 
cently been established In the Portland Center 
for Advanced Technology. Faculty members 
have access to a number of computer installa¬ 
tions for research purposes Including a VAX 
11/780; IBM 4381, Gould 9000, a number of POP 
11 Installations and a CDC Cyber system. In 
addition, the Department of Electrical Engineer¬ 
ing has state-of-the-art laboratory facilities In 
computer graphics and micro computer sys¬ 
tems. Responsibilities Include undergraduate 
and graduate teaching, development of spon¬ 
sored research and interaction with local 
industry. 

Portland has a rapidly-growing computer and 
electronics Industry including Tektronix (world 
headquarters), Intel, Hewlett-Packard, Floating 
Point Systems (headquarters), Electro-Scientific 
Industries, Northwest Instruments, Sequent 
Computer Systems, Metheus, Mentor Graphics, 
Oregon Software, Lattice, etc., which permits 
close industry-university Interaction. 

During the past three years, the computer and 
electronics Industry, the State of Oregon, and 
the City of Portland have launched major Initia¬ 
tives to expand computer science and electrical 
engineering education and research. These in¬ 
clude $3 million distributed by the Oregon High 
Technology Consortium, a $3.5 million five-year 
program funded by the Tektronix Foundation, 
and the acquisition of a 30,000 square foot facili¬ 
ty (the Portland Center for Advanced Technol¬ 
ogy) which houses the Departments of Com¬ 
puter Science and Electrical Engineering. 

While this search is primarily for experienced fa¬ 
culty, we also strongly encourage recent grad¬ 
uates to apply. Rank and salary are commen¬ 
surate with qualifications and experience. Send 
an application, including a resume listing the 
names of three references to: 

Dr. P.A. Frick, Department Head 
Electrical Engineering Department 
Portland State University 
PO Box 751 

Portland, Oregon 97207 
Telephone: (503) 229-3806 
Non-U.S. residents must state their visa status. 
Portland State University is an equal oppor¬ 
tunity/affirmative action employer. Qualified 
minorities, women, and members of other pro¬ 
tected groups are encouraged to apply. 


NATIONAL INVENTOR’S EXPOSITION 

Ideas, inventions, new products wanted by one 
of America’s leading invention submission firms 
to submit to industry and exhibit at National In¬ 
ventor's Exposition. Call free 1-800-528-6050. 
Canada, 1-800-528-6060. Extension 831. Or write: 
ISC-COMP, 903 Liberty Avenue, Pittsburgh, PA 
15222. 
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RESEARCH SCIENTIST 

OCLC, Online Computer Library Center, Inc., has 
an opening at Its corporate headquarters (Co¬ 
lumbus, OH metro area) for a Research Scientist. 
Appropriate candidates should have an exper¬ 
tise and intellectual interest in and the ability to 
carry out independent research projects in one 
of the following areas: library needs and ser¬ 
vices, library automation, information science, 
artificial Intelligence, database systems, user 
interface, telecommunications. Candidates 
should also have a Ph.D. or equivalent exper¬ 
ience in a discipline relative to the above prod¬ 
ucts (such as Computer Science, Information 
Science or Library Science), experience in a 
research environment, and excellent verbal and 
written communication skills. Competitive sal¬ 
ary and a comprehensive benefits package will 
be offered. For position description and com¬ 
pany information, contact: Bill Wolfe, Technical 
Employment Representative, 6565 Frantz Rd., 
Dublin, OH 43017. Phone: 1-614- 764-6097. An 
Equal Opportunity Employer M/F 

CORNELL UNIVERSITY 
Faculty Position 

in Telecommunications 

The School of Electrical Engineering at Cornell 
University invites applications for a tenure-track 
junior faculty position in Telecommunications. 
Candidates with expertise and interests In op¬ 
tical communication systems, digital switching 
and networking, software and hardware for 
telecommunications, and related areas are en¬ 
couraged to apply. 

Interested persons should contact Professor 
J. A. Nation, Director, School of Electrical Engi¬ 
neering, Phillips Hall, Cornell University, Ithaca, 
New York, 14853. 

Cornell University Is an Equal Opportunity, Affir¬ 
mative Action Employer. 


RENSSELAER POLYTECHNIC INSTITUTE 

Applications are invited for full-time, tenure- 
track positions in the Computer Engineering 
Program of the Electrical, Computer, and 
Systems Engineering Department. Applicants 
should have a doctorate in computer engineer¬ 
ing, electrical engineering or computer science, 
with an interest in an academic career combin¬ 
ing research and teaching. Areas of particular in¬ 
terest at this time are computer architecture and 
parallel processing, hardware design, distrib¬ 
uted computing, CAD and VSLI design. 

The department has 45 full-time faculty mem¬ 
bers and approximately $4M in externally spon¬ 
sored research. Last year it awarded 25 doctoral 
degrees, 125 masters degrees, and 225 baccalau¬ 
reate degrees. It also maintains close ties with 
the Computer Science Department in the School 
of Science and with the interdisciplinary Center 
for Integrated Electronics. 

The available positions are principally at the 
Assistant or Associate Professor level. Inter¬ 
ested persons should send detailed resumes to: 
Dr. Lester A. Gerhardt, Chairman 
Electrical, Computer, and Systems 
Engineering Department 
Rensselaer Polytechnic Institute 
Troy, New York 12180-3590 
R.P. I. is an EO/AA Employer 


OPERATIONS ENGINEER 
(COMPUTER SYSTEM) 

Develop satellite computer diagnostic systems 
for CT scanning, develop computer linkup for 
distant catscan, ultrasound, radiological labs, 
using MICOM modems, multiplexers, line 
drivers, and other communication systems; work 
with IBM, DEC, VAX computers, and UNIX and 
TOPS-20 operating systems; analyze operational 


Call for Papers 

continued from p. 141 

Second International Conference on 
Computers and Applications: June 
24-26, 1987, Beijing, China. Long and short 
papers are sought. Long papers will be judged 
on the basis of a 100-word abstract and the 
full text (20 double-spaced pages maximum); 
short papers will be judged on the basis of a 
100-word abstract and a summary of 1000 
words. To submit a paper in either category, 
send four copies of both required items by 
August 31,1986, to Oscar N. Garcia, Dept, 
of Electrical Engineering and Computer 
Science, Room T-637, George Washington 
University, 801 —22nd St., NW, Washington 
DC 20052; (202) 676-7175 or Zhang Xiao- 
xiang, Institute of Computing Technology, 
Academia Sinica, PO Box 2704; 100080 Bei¬ 
jing, China; phone 283131, ext. 556. 

Ninth IEEE International Conference 
^ on Software Engineering (ACM): 

March 30-April 2, 1987, Monterey, Califor¬ 
nia. Submit four copies of a paper (6000 
words maximum; a full-page figure equals 
300 words) that includes a short abstract and 
a list of keywords by September 1,1986, to 
Robert Balzer, Information Sciences Institute, 
4676 Admiralty Way, Marina del Rey, CA 
90291 or Kouichi Kishida, Software Research 
Associates, 1-1-1, Hirakawa-cho, Chiyoda- 
ku, Tokyo 102, Japan. 


Tapsoft 87, Joint Conference on Theory and 
Practice of Software Development: March 
23-27, 1987, Pisa, Italy. Papers are sought for 
two conference events: (1) the Colloquium on 
Trees in Algebra and Programming and (2) 
the Colloquium on Functional and Logic Pro¬ 
gramming and Specifications. To have a 
paper considered for presentation at either 
colloquium, submit five copies of a draft ver¬ 
sion (10 to 15 pages) by September 1, 1986. 
Submit papers for Colloquium One to Ugo 
Montanari, Dipartimento di Informatica, 
Universita di Pisa, Corso Italia 40 1-56100 
Pisa, Italy. For Colloquium Two, submit 
them to Giorgio Levi, Dipartimento di Infor¬ 
matica, Universita di Pisa, Corso Italia 40 
1-56100 Pisa, Italy. 


CSC-87, 1987 ACM Computer Science Con¬ 
ference: February 17-19, 1987, St. Louis, 
Missouri. Papers (10 pages maximum) that 
are suitable for 20-minute presentations are 
sought. Submit five copies by September 5, 
1986, to Arlan R. DeKock or George Zobrist, 
MCS 325, University of Missouri-Rolla, 

Rolla, MO 65401; (314) 341-4492. Short 
reports on current research activities are also 
sought (these should be suitable for 12-minute 
presentations and will be judged on the basis 
of a 500-word abstract), as are proposals for 
panel sessions and tutorials. Submit materials 


problems in software and expand software to In¬ 
clude different modalities such as CT simula¬ 
tion/radiation simulation; work with Fortran, 
C-language computer languages; prepare 
models of software and computer hardware 
operational problems and specify manipulative 
or computational solutions; evaluate Implemen¬ 
tation and effectiveness of system development. 
M.S. (Industrial or Operation or Systems) plus 
one year experience In satellite computer 
system operation/maintenance required. Must 
have hands-on 1-year experience with UNIX and 
TOPS-20 operating systems and working 
knowledge of IBM, DEC, VAX computers and 
Fortran and C-languages. No smoking on the job. 
Salary $27,300 per year. 8:00-5:30 Monday-Frlday. 
Job site and interview Camarillo, California. 
Send this ad and a resume to Job #MLU #3966, 
P.O. Box 9560, Sacramento, CA 95823-0560, not 
later than 1 August 1986. 


CAD SYSTEMS DEVELOPMENT ENGINEER 

CAD SYSTEMS DEVELOPMENT ENGINEER 
with young, small company specializing In Inter¬ 
active graphical systems for engineering stress 
analysis, structural design, and architecture. 
Tasks include planning, design, programming, 
documentation, Implementation, and mainte¬ 
nance of state-of-the-art systems; and supervi¬ 
sion of other professionals Involved In these 
tasks. Applicants must have: graduate degree 
(Ph.D. preferred) In structural engineering or 
engineering mechanics; background In both 
numerical methods and CAD system design; 
programming experience in 3D Interactive 
vector-refresh and raster-color graphics. Salary 
range $39,000-$48,000 depending on qualifica¬ 
tions and experience; full fringe benefits. 
Resume and references to INT 51, NYS Job Ser¬ 
vice, 677 S. SallnaSt„ Syracuse, NY 13202. Refer 
Order No. NY 0000437. 


in these three categories by the same date to 
Arlan DeKock or George Zobrist. 

18th Annual Sigcse Technical Symposium 

(ACM): February 19-20, 1987, St. Louis, 
Missouri. Along with statement of intention 
to attend, submit five copies of the complete 
paper by September 5, 1986, to Dan C. St. 
Clair, Computer Science Dept. UMR, UMSL 
Campus, 8001 Natural Bridge Rd., St. Louis, 
MO 63121-4499. 

IEEE Transactions on Software Engi- 
neering: Articles are sought for a special 
issue on software for local area networks. 
Submit six copies of the article and an IEEE 
copyright release form by September 15, 

1986, to Sushil Jajodia, Naval Research 
Laboratory, Code 7594, Washington DC 
20375; (202) 767-3596 or Satish K. Tripathi, 
Dept, of Computer Science, University of 
Maryland, College Park, MD 20742; (301) 
454-5165. 


1987 ACM Sigmetrics Conference on 
Measurement and Modeling of Computer 
Systems: May 11-14, 1987, Banff, Alberta, 
Canada. Send six copies of paper (5000 words 
maximum) by September 23, 1986, to Derek 
L. Eager, Dept, of Computational Science, 
University of Saskatchewan, Saskatoon S7N 
0W0, Canada. 
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| NEXT IN COMPUTER 


“Parallel computing, long a notorious hangout 
for Utopians, theorists, and backyard tinkerers, 
has almost arrived and is definitely for sale," says 
special issue editor David Gelernter. Although 
hardware featuring as many as 64,000 processors 
is now on the market, how to make this sheer 
power function in a unified, technologically 
significant way remains one of the biggest 
challenges that software engineers have to face. 
COMPUTER looks at currently available and 
possible solutions to the problem of harnessing 
parallel computer horsepower and the new 
potential it holds out for reaching that ever- 
elusive goal: the elimination of programming. 
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I need more information on the following: 
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Products purchased or specified: 
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Data Communication 
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Memories/components 
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Software and Services 
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Publications 
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170 Please send me the IEEE-CS 1986 Publications 
catalog. 

171 Please send me an application for advancement to 
senior member. 

172 Please send me an IEEE-CS membership application. 


Void after 1/15/87 
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I need more information on the following: 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 
15 16 17 18 19 20 21 22 23 24 25 26 27 28 
29 30 31 32 33 34 35 36 37 38 39 40 41 42 
43 44 45 46 47 48 49 50 51 52 53 54 55 56 
57 58 59 60 61 62 63 64 65 66 67 68 69 70 
71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 


Products purchased or specified: 

Hobby Job 


Computers 150 151 

Peripherals 152 153 

Data Communication 154 155 

Memories/components 156 157 

Software and Services 158 159 

Publications 160 161 


170 Please send me the IEEE-CS 1986 Publications 
catalog. 

171 Please send me an application for advancement to 
senior member. 

172 Please send me an IEEE-CS membership application. 
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\AR PROGRAM 


Whenyou weigh the facts, 
the answer to all your AI needs 
is LMI. 


Selecting the right vendor 
to handle your company’s 
Artificial Intelligence 
requirements is a task that 
shouldn’t be taken lightly. 

Several considerations are 
likely to have a heavy impact 
on your final decision. 

At LMI, we’ve addressed 
these weighty issues to 
ensure that the scales will 
always tip in your favor. 

#1. Multi-processor, Multi-user 
workstation 

LMI’s Lambda™ provides a multi¬ 
processor, multi-user AI development 
environment that offers single-user 
performance for as low as $45,000 per seat. 
#2. UNIX ™ & Symbolic Processing 

In addition to its tagged-memory 
LISP processor, the Lambda family 
supports an MC68010 co-processor 
executing System V UNIX.™ This 
means you can integrate your 
current UNIX software into the AI 
development environment or add a 
real-time data acquisition system to 
your AI application. 

#5. Portability 

AI software developed on the 
Lambda is easily portable to your 
existing computer resources 
running CommonLISP because 
LMI offers software packages and 
software tools that enhance the 
usefulness of CommonLISP on 
these computer systems. One 
such tool is ObjectLISP,™ an 
object-oriented programming 
paradigm that’s portable to 
workstations like SUN (Lucid), 

Silicon Graphics (Franz), IBM 
PC/AT (Gold Hill), DEC 
VAX/VMS, DEC MicroVax, 
and the TI Explorer. / y. 


#4. Software Development 

Software environments 
available on the Lambda 
include ZETALISP-PLUS,™ 
LM-Prolog, ObjectLISP, 
CommonLISP, UNIX V, 
FORTRAN, PASCAL, ADA, 
etc. Development tools on 
Lambda, which speed soft¬ 
ware development, include: 
FLAVORS, ZMACS editors, a 
window system, error handlers, 
an Inspector, a file system, and an 
On-Line Documentation Manager.™ 
#5. Performance/Price 
The tagged architecture of the Lambda, 
the recent software enhancements, the 
superior real-time volatility-based garbage 
collector, the unique micro-compiler, and 
<Kr . A the integral MULTIBUS™ combine to 

MTTTTTPROrFCf^X provide you with the highest perfor- 
MUU H \ mance/price ratio in the industry. 

#6. Value-Added Resale Program 

In addition to expert system tools 
and third-party software, LMI offers 
a VAR program that includes 


discounts for development 
systems, product training, and 
marketing support. 
For more information, please 
contact LMI’s Marketing 
Department at 617-682-0500 or 
write to LMI at 6 Tech Drive, 
Building #4, Andover, MA 01810. 




m V UNIX are trademarks of Bell Laboratories. MULTIBUS is a trademark of The Intel Corp. Copyright © 1986 LISP Machine, Inc. 
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RuleMaster? 


“Yes! It’s a proven 

expert system builder.’’ « Even industria i scakr 


“It automatically generates rules 
from case examples. Even the PC 
system can handle more than 1000 
optimized rules in 640k bytes.” 


“It’s not a shell or purely 

- rule based, but a ‘programming 

environment’ for expert system 
development.” 


“C programming skills are not 

required, but RuleMaster does generate - 

C source code for those who want to 
interface with other programs.” 

“And was designed for computer 
professionals and users without AI — 
experience or training.” 


“But, if you want training, 
“For UNIX VMS ^ ere are re S u ^ ar b scheduled 

and DOS computers.” courses. 



RuleMaster-an affordable expert system builder - 
provides for fast execution of completed expert systems. 

In addition to the features mentioned above, the expert 
systems developed with RuleMaster/PC are upwardly 
compatible with RuleMaster running on larger computing 
facilities. 

Technical documents describing successful expert systems 
developed with RuleMaster will be sent to you on request. 


For more information contact: 

RADIAN 

RuleMaster 

(512)454-4797 
8501 Mo-Pac Blvd. 

P.O. Box 9948 
Austin, TX 78766 

A company of The Hartford Steam Boiler 
Inspection and Insurance Company 
i is a trademark of Digital Equipment Corporation 


























